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ABSTRACT 


This  Users  Manual  presents  a  suaaary  of  the  Defense  Mapping 
Agency  (DMA)  Prograaaing  Support  Library  (PSL)  system,  a 
description  of  the  PSL  processing,  and  a  guide  for  users  of 
the  syatea.  This  docuaent  is  prepared  for  those  who  need  an 
overall  understanding  of  the  system  and  for  those  who  meed 
aore  detailed  technical  information  on  the  use  of  the  system 
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SECTION  1.  GENERAL  DESCRIPTION 

1 • 1  Purpose 

The  Defense  Mapping  Agency  (DMA)  Programming  Support  Library 
(PSL)  is  a  software  system  which  provides  the  tools  to 
organize,  implement,  and  control  computer  program  development. 

The  system  is  designed  specifically  to  support  top-down 
development  and  structured  programming,  but  non-structured 
programs  can  also  be  accommodated.  This  Users  Manual  provides 
the  documentation  required  to  initialize  and  develop  a 
programming  project  under  the  PSL  system  in  a  batch  mode  on 
Sperry  Unlvac  1100  series  hardware. 

The  Users  Manual  is  organized  such  that  the  text  becomes 
increasingly  detailed  and  specific  as  the  reader  progresses. 

The  general  progression  is  as  follows: 

a.  Section  1  -  General  Description.  This  section  is 
devoted  to  the  general  concept  of  the  new  programming 
techniques  and  summarizes  relevant  reference 
material. 

b.  Section  2  -  System  Summary.  This  section  describes 
the  general  capabilities  of  the  PSL  system  and  the 
concept  of  a  programming  library. 

c.  Section  3  -  Technical  Operation.  This  section 
describes  the  specific  capabilities  of  the 
system,  in  the  following  order: 

(1)  Subsection  3.1  -  Overview  of  Input  Requirements. 

This  subsection  describes  the  basic  capabllir  es 
of  each  Function  directive  which  may  be  processed 
by  the  PSL  system.  The  overview  is  intended  to 
give  the  user  a  high-level  introduction  to  the 
use  of  the  system  before  specific  details  of 
format  are  Introduced.  The  Function  directives 
are  discussed  in  the  order  in  which  they  would 
logically  occur  in  actual  use. 

(2)  Subsection  3.2  -  Composition  Guides.  This 
subsection  covers  many  miscellaneous  technical 
items  which  have  general  application  to  more 
than  one  PSL  Function  directive. 
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(3) 


Subsection  3.3  -  Conventions  end  Glossary. 
These  items  establish  standards  of  format 
and  vocabulary  to  be  used  in  subsection 
3.4. 


(4)  Subsection  3.4  -  Input  Format  of  Function 
Cards.  This  subsection  discusses  each  PSL 
Function  directive  in  detail.  It  is  Intended 
to  be  used  as  reference  material  and  is 
arranged  in  alphabetical  order  by  Function. 

1  •  2  Project  Bac  round 

There  have  been,  from  the  beginning  of  programming  activities, 
certain  principles  that  good  programmers  have  identified  and 
practiced  in  one  way  or  another.  These  Include:  developing 
system  designs  from  a  gross  level  to  more  and  more  detail  until 
the  detail  of  a  computer  operation  is  reached;  dividing  a  system 
into  modules  in  such  a  way  that  minimal  interaction  takes  place 
through  module  Interfaces;  and  using  meaningful  terms  in  the 
coding  process. 

Two  key  principles,  which  are  new  in  their  application  to  pro¬ 
gramming,  will  play  a  major  role  in  the  implementation  and 
exploitation  of  these  ideas. 

The  first  key  technical  principle  is  that  the  control  logic 
of  any  program  can  be  designed  and  coded  In  a  highly  structured 
way.  In  fact,  arbitrarily  large  and  complex  programs  can  be 
represented  by  iterating  and  nesting  a  small  number  of  basic 
and  standard  control  logic  structures. 

A  practical  application  of  this  first  principle  is  the  writing 
of  structured  programs,  i.e.,  programs  in  which  the  branching 
control  logic  can  be  defined  entirely  in  terms  of  DO  loops, 
IF-THEN-ELSE ,  and  sequences.  The  resulting  code  can  be  read 
strictly  from  top  to  botton,  typographically,  and  is  much  more 
easily  understood.  It  takes  more  skill  and  analysis  to  write 
such  code,  but  its  debugging  and  maintenance  are  greatly 
simplified.  Even  more  Importantly,  such  structured  programming 
can  increase  a  single  programmer's  span  of  detailed  control  and 
productivity  by  a  large  amount. 

The  second  key  technical  principle  is  that  programs  can  be 
coded  on  a  schedule  that  requires  no  simultaneous  interface 
assumptions.  Programs  can  be  coded  in  such  a  way  that  every 
interface  is  defined  initially  and  uniquely  in  the  coding 
process  itself,  and  referred  to  thereafter  only  in  its  pre¬ 
viously  coded  form. 


In  practical  application,  this  second  principle  leads  to  top-down 
development,  where  code  is  generated  In  an  execution  precedence 
fora.  In  this  case,  programmers  write  job  control  code  first, 
then  linkage  code,  and  then  aource  code.  The  opposite  (and 
typical  implementation  procedure)  is  bottom-up  programming, 
where  source  modules  are  written  and  unit  tested  first,  and 
later  integrated  into  subsystems  and,  finally,  systems.  This 
latter  Integration  process,  in  fact,  tests  the  proposed  solutions 
of  simultaneous  interface  problems  generated  by  lower-level 
programming;  and  the  problems  of  system  integration  and  debugging 
arise  from  imperfections  in  these  proposed  solutions.  Top-down 
programming  circumvents  the  Integration  problem  by  the  coding 
sequence  itself. 

1.2.1  Structured  Programming 

Structured  programming  is  based  on  a  mathematically  proven 
"Structure  Theorem"  which  states  that  any  program  with  one  entry 
and  one  exit  is  equivalent  to  a  program  that  contains  combinations 
of,  at  the  most,  the  following  logic  structures: 

a.  Sequence  of  statements 

b.  IF-THEN-ELSE 

c.  DO-WHILE 

Sequence  logic  structure  is  represented  by  the  following 
diagram: 


FUNCTION 

FUNCTION 

A 

W 

B 

This  logic  structure  is  the  simplest  and  indicates  that  function 
A  is  to  be  performed  first,  function  B  is  to  be  performed  next, 
and  then  processing  is  to  continue. 
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The  second  of  these  basic  structures,  the  IF-THEH-ELSE  figure, 
can  be  represented  by  the  following  diagram: 


In  this  basic  structure,  the  flow  of  control  is  governed  by 
the  condition  C.  If  condition  C  is  true,  function  D  is  per¬ 
formed.  In  either  case,  control  returns  to  a  common  node  and 
proceeds  from  that  node. 

The  third  basic  structure,  the  DO-WHILE  figure,  is  represented 
as  follows: 


In  this  basic  logic  structure,  the  flow  of  control  again  is 
governed  by  a  condition.  Function  G  is  performed  while  con¬ 
dition  F  is  true.  Vhen  condition  F  is  no  longer  true,  the 
flow  of  control  falls  through  and  processing  continues. 
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The  three  figure*  discussed  ebove  (Sequence,  IF-THEN-ELSE , 
and  DO-VHILE)  are  the  basic  figures  of  the  structured  pro¬ 
gramming  theory.  Other  figures  which  one  might  implement 
sre  based  on  combinations  of  these  figures. 

A  standard  extension  of  the  three  basic  figures  is  the 
DO-UNTIL  figure,  which  is  logically  equivalent  to  a  Sequence 
figure  followed  by  a  DO-WHILE  figure.  The  DO-UNTIL  figure 
is  represented  as  follows: 


In  this  structure,  function  L  la  always  performed  at  least 
once.  Function  L  will  be  repeated  until  condition  M  is 
true.  Note  that  the  flow  of  control  fells  through  on  a 
true  condition,  in  contrast  to  a  DO-WHILE  figure,  where 
the  flow  falls  through  on  a  false  condition. 

Another  extension  to  the  basic  figures  is  the  CASE  logic 
structure.  Although  the  CASE  figure  cen  be  represented 
by  a  series  of  IF-THEN-ELSE  figures,  it  is  often  desirable 
to  represent  this  situation  by  the  following  structure: 


In  the  CASE  logic  structure,  the  flow  of  control  is  governed 
by  the  velue  of  A.  If  A  Is  correctly  evelueted  es  1,  then 
function  B  Is  perforned.  If  A  is  2,  function  C  Is  perforaed. 
For  all  other  evaluations  of  A,  function  N  Is  perforaed.  In 
every  case,  control  returns  to  a  coaaon  noda  and  proceeds 
from  that  node. 

The  logic  figures  described  above  are  useful  at  all  phases  of 
development.  Including  the  design  phase.  Using  the  figures 
with  non-programming  text,  a  prograaaar  can  provide  procedural 
definitions  at  any  level  of  completeness  in  a  fora  referred  to 
as  Program  Design  Language  (PDL).  As  the  design  materialises , 
the  PDL  text  can  evolve,  in  top-down  fashion.  Into  the  imple¬ 
mentation  (programming)  language  of  choice. 
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1.2.2  Preprocessors 

The  implementation  of  the  baaic  logic  figurea  will  depend  to 
some  degree  on  the  programming  language  being  uaed.  Once  the 
baaic  figurea  are  implemented,  however,  the  use  of  these 
figures  will  enhance  the  ability  of  programmers  to  understand 
and  verify  each  other's  programs. 

The  logic  structures  used  in  the  American  National  Standard 
(ANS)  COBOL  language,  for  example,  do  not  correspond  to  those 
of  structured  programming.  A  specific  case  is  the  use  of  a 
dependent  IF  clause  which  is  limited  to  logic  which  only 
progresses  downward.  (A  dependent  IF  clause  cannot  be 
terminated  without  terminating  the  higher-level  IF  (or  ELSE) 
code  on  which  it  is  dependent.)  In  addition,  the  use  of  a 
PERFORM  statement  to  accomplish  the  logic  of  a  DO-WHILE 
structure  results  in  code  vhlch  is  dispersed  over  many  pages 
and  introduces  confusion  to  a  programmer  reading  the  code. 

In  order  to  support  these  structures  more  precisely,  preprocessors 
(also  referred  to  as  precompilers)  are  used  to  read  the  struc¬ 
tured  source  code  and  to  generate  new  source  code  which  is 
subsequently  compiled.  The  new  code  is  not  necessarily  in 
structured  format,  but  the  programmer  does  not  work  with  this 
code.  It  is  an  intermediate  product  between  his  source  code 
and  his  object  code. 

A  General  Preprocessor  has  been  added  to  handle  unstructured 
source  code  for  the  following  languages:  ASM,  .COBOL,  FORTRAN, 
and  JOVIAL.  This  General  Preprocessor  is  an  alternative  to  the 
method  in  section  3.2.3  for  dealing  with  unstructured  source 
code.  A  user  description  of  the  General  Preprocessor  is  given 
in  Appendix  I. 

The  preprocessors  «lso  support  the  segmentation  of  source  code 
into  page-size  segments  called  units  by  allowing  the  programmer 
to  INCLUDE  additional  units  into  his  input  stream. 
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1.2.3  Top-Down  D«v»lopmt 

Top-down  prograa  developaent  requires  that  prograaalng  proceed 
froa  the  control  stateaents  downward  until  all  functional  units 
are  developed  and  Integrated.  The  process  provides  continuous 
integration  of  the  systea  parts  as  they  are  prograaaed . 

Conceptually,  top-d^wn  developaent  proceeds  downward  froa  a 
single  starting  point,  while  conventional  lapleaentatlon 
proceeds  upwards  froa  as  aany  starting  points  as  there  are 
aodules  In  the  design.  The  single  starting  point  does  not 
laply  that  lapleaentatlon  Bust  proceed  down  the  hierarchy 
In  parallel.  Soae  branches  asy  be  developed  earlier  than 
others  in  order  to  obtain  soae  Initial  operational  capabilities. 

Each  prograa  or  aodule  within  the  systea  should  also  be 
developed  froa  the  top  downward.  The  saae  rules  and  benefits 
apply  to  single  prograas  and  to  coaplete  systeas .  A  basic 
rule  for  software  developaent  using  the  top-down  approach 
is  that  code  being  developed  depends  only  on  operational 
code . 

A  separate  systea  Integration  period  is  ellalnated  by  top-down 
developaent,  since  the  systea  parts  are  continuously  Integrated. 
In  effect,  the  higher-level  code  becoaas  the  driver  prograa  for 
the  aost  critical  units  are  also  the  aost  tested. 

Since  the  higher-level  units  will  noraally  Invoke  lower-level 
units,  duaay  code  (stubs)  are  substituted  teaporarlly  for  the 
lower-level  units  to  preserve  the  designed  Interface.  The 
lower-level  units  are  expanded  and  tested  after  the  higher-level 
units  arc  tested  and  Integrated.  This  procedure  Is  Iterated 
downward,  substituting  actual  prograa  units  at  each  successively 
lower  level  until  the  entire  systea  has  been  Integrated  and 
tested . 

Top-down  developaent  provides  the  ability  to  evolve  a  product 
which  Is  always  operable,  aodular,  and  available  for  testing. 

The  quality  of  a  systea  which  is  produced  using  the  top-down 
approach  Is  increased  through  the  earlier  detection  and 
cllainatlon  of  design  probleas  and  coding  errors. 
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1.2.4  Development  Support  Library 

Top-down  prograaa  which  are  written  to  be  highly  readable , 
and  whoae  aajor  atructural  characteristic*  are  given  In 
hierarchlal  top-down  fora,  can  be  read  sequentially.  The 
prograaa  are  written  In  swell  segaenta  (units),  usually 
under  a  page  In  length,  auch  that  each  segaent  can  be 
literally  read  froa  top  to  bottoa,  with  coaplete  assurance 
that  all  control  paths  are  visible  In  the  aegaent  under 
consideration . 

There  are  two  requireaents  through  which  one  can  achieve 
this  goal.  The  first  requireaent  Is  structured  prograaalng 
i.e.,  the  foraulatlon  of  prograaa  in  teraa  of  a  few  standard 
and  basic  control  structures,  such  as  IF-THEN-ELSE  statements, 
DO  loops,  and  CASE  atateaenta,  with  no  arbitrary  jumps 
between  these  standard  structures.  The  second  requireaent 
is  library  support,  ao  that  the  segaenta  themselves  can  be 
stored  under  symbolic  names  In  a  library  and  substituted 
at  any  point  in  a  program  by  a  special  statement  (INCLUDE) . 

A  key  aspect  of  any  INCLUDEd  unit  Is  that  Its  control  should 
enter  at  the  top  and  exit  at  the  bottoa,  and  have  no  other 
aeans  of  entry  to,  or  exit  from,  other  parts  of  the  program. 
Thus,  when  reading  an  INCLUDE  statement,  at  any  point,  the 
reader  can  be  assured  that  control  will  pass  through  that 
INCLUDEd  unit  and  not  otherwise  affect  the  control  logic  on 
the  page  he  is  reading. 

A  unit  of  code  Is  usually  limited  to  50  lines  or  less.  Each 
unit  of  code  (whose  Internal  operations  may  be  any  combina¬ 
tion  of  the  basic  logic  structures)  must  itself  represent 
one  of  the  basic  logic  structures.  Thus,  each  code  unit 
becomes  a  logical  entity  to  be  analysed,  coded,  and  read  at 
one  time. 

In  order  to  satisfy  the  unit  entry/exit  requireaent,  one  need 
only  be  sure  to  Include  all  aatchlng  control  logic  statements 
on  e  page.  For  example,  the  ENDDO  to  any  DO,  and  the  ENDIF  to 
any  IF-THEN-ELSE ,  should  be  put  In  the  same  unit. 

The  end  result  la  a  program,  of  any  else  whatsoever,  which 
hes  been  organised  into  a  set  of  naaed  aeaber  units,  each  of 
which  can  be  read  froa  top  to  bottoa  without  any  side  effects 
In  control  logic,  other  than  what  la  on  that  particular  page. 

A  prograaaer  can  access  any  level  of  inforaation  about  the 
program,  froa  highly  summarised,  at  the  upper-level  segaenta, 
to  completely  detailed.  In  the  lower  level. 
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A  development  support  library  is  required  to  support  such  a 
programming  effort  and  to  provide  project  visibility.  The 
library  system  should  be  designed  to  support  a  top-down 
structured  environment.  The  princlpel  objective  of  the 
llbrery  Is  to  provide  constantly  up-to-date  representations 
of  the  program  segments  and  test  data.  In  both  machine- 
readable  and  hard-copy  forms.  In  addition,  the  library 
provides  the  capability  to  obtain  development  status  Informa¬ 
tion  for  management  control.  The  library  Is  designed  to 
malnteln  the  current  status  of  such  Items  as  test  data, 
control  data,  source  data,  object  modules,  and  load  modules. 

A  librarian  may  be  used  to  maintain  the  development  support 
library.  The  librarian,  through  predefined  procedures, 
maintains  the  programs  and  test  data  on  disk  storage.  The 
Information  on  disk  is  referred  to  as  the  Internal  library. 

The  hard-copy,  or  external  library,  is  maintained  with  a 
standard  set  of  office  procedures. 

A  development  project  normally  contains  an  operational  library 
of  code  that  has  been  tested,  and  one  or  more  development 
libraries  for  newly  developed  code.  At  any  point  in  time, 
the  operational  library  constitutes  the  current  operational 
system.  Configuration  control  is  ensured  by  requiring  that 
an  update  to  the  operational  library  be  conditioned  on  proof 
of  successful  testing  In  e  development  library.  This  minimizes 
the  likelihood  of  errors  entering  the  system.  Verification 
procedures  are  reviewed  for  an  update  to  the  operational  library. 
The  development  support  library  thus  provides  the  necessary 
control  to  develop  a  system  In  a  top-down  manner. 

The  procedures  associated  with  the  library  are  designed  to 
support  the  practices  of  top-down  structured  programming. 

For  example.  In  structured  programming,  strict  attention  Is 
paid  to  the  Indentation  of  the  logic  structures  on  the  printed 
page  so  that  logical  relationships  In  the  coding  correspond 
to  physical  position  on  the  listing.  A  pictorial  represen¬ 
tation  of  the  logic  Is  thus  expressed  by  the  indentation. 

The  library  procedure,  which  lists  source  code,  automatically 
sets  up  the  Indentation.  This  method  not  only  eliminates 
work  for  the  programmer,  but  also  assures  the  code  reader 
thet  the  logic  structure  actuelly  follows  the  dependencies 
shown  in  the  listing  and  Is  not  the  result  of  s  mistaken 
essumptlon  by  the  programmer. 


In  addition,  the  library  Input  procedure  aupport  the  practice 
of  unit-level  development  by  providing  a  capability  for 
automatic  stub  generation.  Testing  and  integration  vlll  start 
with  the  highest-level  module  as  soon  as  it  is  coded.  Since 
this  module  will  normally  invoke  or  include  lover-level 
segments,  code  must  exist  for  the  next-lower-level  segment. 

This  code,  in  the  form  of  a  source  stub,  can  be  provided 
automatically  by  the  library  system.  These  stubs  will  later 
be  expanded  into  full  functional  units,  which  in  turn  require 
lower-level  segments. 

The  library  provides  a  central  source  of  status  data  to  measure 
the  development  process.  Parameters,  such  as  the  number  of 
updates  performed,  the  number  of  units  involved,  the  number 
of  source  lines  present,  atd  the  number  of  stubs  remaining, 
can  be  used  to  develop  ma^«geme^t  reports,  and  to  highlight 
problem  areas  which  need  attention. 

Since  the  developing  system  ns  undergoing  continuous  inte¬ 
gration,  the  system  status  is  accurately  reflected  through 
the  contents  of  the  library.  Completness  is  measured 
objectively  in  terms  *>f  how  much  of  the  system  is  operational. 
The  completed  code  can  be  reviewed  to  verify  status  and 
appraise  the  quality  of  the  software  product. 
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1.2.5  Management  Data  Collection  and  Reporting  (MDCR) 

The  purpose  of  the  Management  Data  Collection  and  Reporting 
facility  Is  to  support  the  collecting  and  reporting  of 
management  data  for  a  FSL  project.  Although  designed  as  an 
integral  part  of  the  PSL,  this  facility  Is  optional  and  can 
be  selectively  omitted  at  the  project  level  with  no  effect  on 
other  functions  performed  for  that  project. 

The  MDCR  facility  involves  the  collection  and  storage  of  data 
related  to  program  development  and  maintenance  and  the  gen¬ 
eration  of  management  reports  containing  the  data  and/or 
summaries  of  data.  The  data  collected  Is  stored  In  a  pro¬ 
ject's  Management  Data  Section.  A  Management  Data  Section 
Is  created  and  maintained  for  each  project  for  which  manage¬ 
ment  data  is  collected. 

A  capability  is  provided  to  define  elements  of  the  project 
for  which  menegement  data  Is  to  be  collected.  The  data  Items 
to  be  collected  can  be  specified  and  their  arrangement  In 
subsequent  management  reports  defined.  Manual  data  may  be 
Input  for  collection  and  summarisation  with  data  that  is 
automatically  supplied  from  Unit  Accounting  Records.  Collected 
data  may  be  archived  as  required,  and  both  current  and  archived 
data  can  be  printed  in  defined  report  formats.  Special  capa¬ 
bilities  are  provided  to  annotate  management  reports  when  data 
Item  values  are  outside  allowable  ranges  and  to  support  the 
execution  of  user  routines  to  satisfy  unique  data  collection 
requirements . 
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1.2.6  Summary 

The  techniques  described  in  the  preceding  paragraphs  represent 
a  disciplined  approach  to  application  development,  which  has  as 
its  goal.  Improved  program  quality,  maintainability,  and 
manageability.  The  PSL  system  provides  the  tools  necessary  to 
fully  Implement  these  new  programming  techniques. 

The  facilities  deacrlbed  in  this  manual  constitute  the  imple¬ 
mentation  of  the  PSL  system  for  Rome  Air  Development  Center 
under  Air  Porce  Contract  F30602-77-C-0749.  The  requirements 
for  the  PSL  system  were  developed  as  part  of  the  Structured 
Programming  Series  of  reports,  RADC-TR-74-300 ,  Volume  1  through 
XV,  March  1975,  under  Air  Force  Contract  F30602-74-C-0186 . 

The  following  volumes  have  particular  application  to  the  PSL 
system  development: 


a . 

Volume  11 

- 

Precompiler  Specifications 

b. 

Volume  III 

- 

Precompiler  Program  Documentation 

c . 

Volume  V 

- 

Programming  Support  Library 
Functional  Requirements 

d. 

Volume  VI 

- 

Programming  Support  Library 
Program  Specifications 

e  . 

Volume  IX 

— 

Management  Data  Collection  and 

Reporting 


Precompilers  are  described  in  the  Structured  Programming  Series, 
Volume  Ill.  The  syntax  acceptable  to  these  precompilers  has 
been  modified  under  the  PSL  system  to  additionally  allow  the 
INCLUDE  statement.  PSL  supports  precompilers  for  COBOL,  JOVIAL 
and  FORTRAN.  In  addition,  the  General  Preprocessor  allows  the 
INCLUDE  statement  to  be  used  in  unstructured  ASM,  COBOL, 

FORTRAN  and  JOVIAL.  See  Appendix  I. 

The  COBOL  source  code,  which  is  called  Structured  COBOL  (SCOBOL) 
in  this  manuel,  accepts  the  following  special  sets  of  stetements 

a.  INCLUDE 

CASENTRY 
CASE 

ELSECASE 
ENDCASE 


b. 


c.  DO  WHILE 
ENDDO 

d.  DO  UNTIL 
ENDDO 

e.  IF 
ELSE 
END  IF 

The  use  of  Che  INCLUDE  itatenent  is  described  in  Section  3.2.8 
of  this  Users  Manual.  The  user  should  refer  to  Appendix  G 
for  more  complete  documentation  on  the  use  of  Structured  COBOL. 

The  Structured  FORTRAN  precompiler  is  discussed  in  Appendix  F 
of  this  manual.  The  syntax  acceptable  to  this  precompiler 
allows  the  use  of  standerd  structured  programming  constructs. 

In  addition  to  the  INCLUDE,  CASENTRT ,  DOWHILE ,  DOUNTIL,  and 
IF  statement  seta  listed  above,  the  FORTRAN  precompiler's 
structured  programming  language,  SPFORT,  provides  for  one 
additional  statement  set. 

INVOKE 

BLOCK 

ENDBLOCK 

The  statement  set  performs  a  similar  function  as  that  provided 
by  the  INCLUDE  capability.  Use  of  the  INCLUDE  statement  Is 
described  in  Section  3.2.8.  Use  of  the  INVOKE,  BLOCK,  ENDBLOCK 
construct  la  described  in  Appendix  F. 

The  Structured  JOVIAL  precompiler  is  discussed  in  Appendix  H 
of  this  manual.  The  syntax  acceptable  to  this  precompiler 
contains  the  following  special  sets  of  statements: 

a.  IF 

ELSE  (optional) 

END  IF 

b.  DO  (WHILE  or  UNTIL) 

ENDDO 

c.  CASENTRY 

CASE  (at  least  one  must  be  present) 

ELSECASE  (optional) 

ENDCASE 

d.  INCLUDE 
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SECTION  2.  SYSTEM  SUMMARY 

2 . 1  System  Application 

The  DMA  PSL  is  a  comprehensive  system  software  package  which 
support-s  the  growth  and  maintenance  of  structured  programming 
projects  in  a  top-down  development  environment.  The  system 
provides : 


a.  A  framework  for  the  organization  of  a  project 

b.  Simple  functional  statements  to  Interface  between 
the  programmer  and  the  machine 

c.  Structural  and  statistical  reports  for  control 
of  the  development  process  and  for  communication 
between  programmers. 


The  DMA  PSL  system  provides  special  structured  programming 
support  for  the  Structured  COBOL,  JOVIAL  and  FORTRAN  languages 
However,  unstructured  programs  may  also  be  stored  and  maintained 
under  the  system. 


2 . 2  System  Operation 

The  PSL  system  in  the  batch  mode  is  Invoked  by  an  9ADD ,  @END , 
@ADD  sequence  and  is  directed  to  perform  specific  functions  by 
PSL  Function  cards.  The  general  functional  capabilities 
available  under  the  PSL  are: 

a.  Initialize  a  project 

b.  Create  sections  in  a  library 

c.  Add,  change,  move,  replace,  or  purge  a  unit  of  code 

d.  Print,  punch,  or  write  (to  tape)  a  unit  of  code 

e.  Print  an  index  listing 

f.  Print  the  top-down  structure  of  a  program 

g.  Compile,  link,  execute 

h.  Delete  a  section,  a  library,  or  a  project 

i.  Backup  a  project,  library,  or  section. 

j.  Restore  a  project,  library,  section,  or  unit. 

k.  Collect  and  print  management  data. 
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l.  PrlnC  text  material 

m.  Print  by  author  or  character  string 

The  PSL  Functions  are  described  in  detail  in  Section  3.  The 
capitalized  word  "function"  is  used  to  refer  to  one  of  the  28 
PSL  operations  which  is  invoked  with  a  PSL  card.  A  general 
system  flow  chart  is  shown  in  Figure  2-01. 

2 . 3  System  Configuration 

The  PSL  system  operates  on  an  Sperry  Univac  1100  series  computer 
under  the  Exec  8  Operating  System  using  a  standard  DMA  software 
and  hardware  configuration.  Libraries  are  maintained  on  direct 
access  storage  devices.  The  system  utilizes  the  standard  card 
reader  and  printer,  one  tape  drive,  and  40K  words  of  core. 

2 • 4  System  Organization 

The  PSL  system  is  designed  to  support  the  program  development 
and  maintenance  effort  of  an  entire  organization.  In  a  large 
organization,  the  system  must  support  many  persons  working 
on  different  programming  projects  which  may  be  completely  un¬ 
related.  The  PSL  provides  means  of  maintaining  control  over 
all  the  data  related  to  each  project. 

One  means  of  control  is  the  convention  used  for  identifying 
and  organizing  the  data  (source  code,  compiled  modules, 
tent  data,  etc.)  stored  under  a  project.  This  convention 
subdivides  the  data,  beginning  with  the  programming  project 
level  and  proceeding  down  to  single  logical  units  of  data. 

The  hierarchical  structure  of  a  project  is  shown  In  Figure 
2-02  . 

There  are  four  levels  of  data  identification  under  the  PSL. 

The  highest  level  of  identification  is  a  pro.1  ect .  This 
corresponds  to  a  major  programming  operation  and  consists 
of  all  of  the  data  related  to  that  operation. 

The  next  level  of  identification  is  a  library .  Each  project 
is  composed  of  one  or  more  libraries.  Multiple  libraries 
can  be  used  effectively  to  provide  version  control  over  the 
programming  process  and  to  support  top-down  program  develop¬ 
ment  and  integration.  Any  number  of  libraries  may  exist 
under  a  given  project. 
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Figure  2-02.  Hierarchical  Structure  of  a  Project 
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A  library  la  composed  of  segments  of  programming  data  grouped 
according  to  type  of  data.  Each  type  of  data  is  stored 
in  a  specific  section  of  a  library.  The  names  of  a  section 
is  one  of  the  following  predefined  section  names: 


a . 

SOURCE 

- 

source  code  statements 

b. 

OBJECT 

- 

object  module  Indexes  and  accounting 
records 

c . 

LOAD 

- 

load  module  Indexes  and  accounting 
records 

d. 

LINK 

- 

collector  control  cards 

e . 

JOB 

- 

job  control  cards  used  during 
execution  of  user  program 

f  . 

TEST 

- 

test  data  for  use  by  user  program 

8- 

PDL 

- 

Program  Design  Language  statements 

h. 

TEXT 

- 

documentation 

i. 

MGMT 

- 

management  data 

j- 

USER 

- 

user  generated  data 

k . 

PROGRAM 

— 

relocatable  and  absolute  elements 

The  PSL  system  manipulates  the  data  for  each  section  appro¬ 
priately  for  that  type  of  section. 

A  section  is  composed  of  logical  segments  of  data  called 
units .  The  unit  is  the  lowest  level  of  the  naming  conven¬ 
tion  used  under  the  PSL  system.  A  unit  is  therefore  uniquely 
identified  by  the  following  set: 


a.  Project  name 

b.  Library  name 

c.  Section  name 

d.  Unit  name 
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The  ectuel  structure  end  content  of  e  unit  le  related  to 

the  type  of  section  to  trhlch  the  unit  belongs.  See  Appendix  A 

for  s  more  detailed  discussion  of  the  structure  of  a  section. 

To  support  progrannar  communication  and  managerial  control, 
the  contents  of  the  project  libraries  should  be  available 
for  common  reference.  The  PSL  facilitates  the  parallel 
maintenance  of  programming  data  in  both  computer-readable  and 
hard-copy  form.  The  system  provides  the  necessary  output, 
in  the  form  of  listings  and  summaries,  to  ensure  that  these 
two  libraries  may  be  maintained  in  exact  correspondence. 
Recommended  procedures  for  updating  a  library  and  for  filing 
the  output  are  presented  in  Section  3. 


Section  3.  TECHNICAL  OPERATION 

The  PSL  system  can  be  used  to  support  e  varied  act  of 
programmer  needs,  ranging  from  a  small  program  to  large  and 
complex  systems.  The  user  has  an  extensive  selection  of 
options,  for  which  default  values  are  provided  where  prac¬ 
tical.  Thus  a  programmer  may  begin  to  use  the  system  in  a 
simple  straight-forward  manner  and  gradually  enlist  the 
aid  of  the  more  specialised  services  of  the  system. 

Within  this  section  of  the  Users  Manual,  the  use  of  the  PSL 
system  is  addressed  at  an  Increasingly  detailed  technical 
level.  The  content  of  the  subsections  includes: 

a.  Overview  of  Input  Requirements  (subsection  3.1)  - 
An  overall  view  of  the  use  of  the  PSL  Functions. 
Details  of  format  are  not  covered.  Each  Function 
is  discussed  briefly  under  one  of  the  following 
programming  areas: 

(1)  Library  Maintenance 

(2)  Unit  Maintenance 

(3)  Program  Processing 

(4)  Output  Processing 

(5)  General  Functions 

(6)  Management  Data  Collection 

b.  Composition  Guides  (subsection  3.2)  -  Detailed 
information  on  miscellaneous  general  capabilities 
and  requirements  which  are  related  to  more  than 
one  PSL  Function.  The  user  should  have  some 
understanding  of  the  items  discussed  in  this 
subsection  before  attempting  to  compose  an  Input 
stream  in  accordance  with  the  detailed  explanations 
of  PSL  Functions  given  in  subsection  3.4.  The 
items  discussed  in  section  3.2  are: 

(1)  High-level  parameters 

(2)  Multi-library  search 

(3)  Independent  files 

(4)  File  Management  Space 

(5)  Spawned  joba 

(6)  Stub  generation 

(7)  Error  handling 

(8)  INCLUDE  Statements 

(9)  Name  lengths  and  Restrictions 

(10)  Management  Data  Cycling  and  Archive  Operatlona 

(11)  Special  Case  Card  Data 
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e.  Convent  ion*  and  Glossary  (subsection  3.3)  -  The 
■aanlngs  of  foraats  and  tha  daflnltlona  of  tarns 
uaad  In  Subsactlon  3.4. 

d.  Input  Format  of  Function  Cards  (subsactlon  3.4)  - 
Detailed  explanation  of  a  PSL  Function  card  and  of 
each  FSL  Function.  Tha  Functions  are  arranged 
alphabetically. 

a.  Saapla  Inputs  (subsactlon  3.5)  -  Eafarancas  as 
to  locations  within  this  annual  where  Input 
aaaples  any  be  found. 

f.  Procedures  for  Output  (subsactlon  3.6)  -  Procedures 
for  aalntalnlng  an  axtarnal  library. 
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3 . 1  Overview  of  Input  Requirements 


The  following  peregrephe  describe  Input  requirements  at  a  fairly 
elementary  level  In  order  to  present  the  basic  uses  of  the  PSL 
system  In  as  simple  a  manner  as  possible.  Many  options  and 
varied  approaches  are  Intentionally  Ignored  In  this  subsection* 

In  addition,  abbreviations  and  short-cuts  are  not  used  in  the 
examples,  since  they  would  detract  from  the  understanding  of 
the  basic  Functions.  For  a  fuller  and  more  precise  understanding 
of  the  use  of  the  system,  the  user  should  read  the  discussion 
of  Input  formats  in  subsection  3.2  and  the  detailed  descriptions 
of  the  Functions  In  subsection  3.4. 

The  input  to  the  PSL  system  consists  of  directives  on  Input 
cards  (PSL  Function  cards),  data  from  the  user's  libraries, 
and.  In  some  Instances,  an  input  tape.  The  PSL  system  accepts 
PSL  Function  cards  as  batch-input  data  cards.  The  user's 
own  program  and  data  cards  are  interspersed,  as  necessary, 
with  the  PSL  Function  cards.  The  characters  In  columns 

1  through  3  identify  a  card  as  a  PSL  Function  card  or  a 
Function  continuation  card.  The  PSL  cards  contain  the  name 
of  a  Function  requested  and,  if  appropriate,  sets  of  keywords 
and  value-entries.  Note  that  the  examples  given  below  and  In 
subsection  3.4  represent  card  input  to  the  PSL  system. 

In  this  overview,  the  PSL  Functions  are  arranged  In  groups 
which  are  related  in  general  capability.  The  capability 
groups  and  the  functions  under  each  of  these  groups  are: 

a.  Library  Maintenance 

(1)  INITIAL  -  Initialize  a  project 

(2)  CREATE  -  Create  s  section 

(3)  BACKUP  -  Backup 

(4)  RESTORE  -  Restore 

(5)  TERMINATE  -  Delete  a  section 

b.  Unit  Maintenance 

(1)  ADD  -  Add  a  unit 

(2)  REPLACE  -  Replace  a  unit 

(3)  CHANGE  -  Change  a  unit 

(4)  MOVE  -  Move  a  unit 

(5)  PURGE  -  Dslcte  a  unit 
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Program  Processing 


(1)  COMPILE  -  Compile  e  module 

(2)  LIME  -  Link  e  program 

(3)  EXECUTE  -  Execute  a  program 

Output  Processing 

(1)  INDEX  -  Print  a  section  index 

(2)  SOURCE  -  Output  a  unit 

(3)  MDPR1NT  -  Print  reports 

(4)  DOCUMENT  -  Print  text 

(5)  AUTHOR  -  Print  by  author 

(6)  CSCAN  -  Print  by  character  string 

General  Functions 

(1)  PARAM  -  Establish  high-level  parameters 

(2)  JCL  -  Insert  extra  JCL  into  spawned  job 

Management  Data  Collection 

(1)  MDPLAN  -  Maintain  the  data  collection  and 

storage  plan 

(2)  MDFORMAT  -  Maintain  management  data  formats 

(3)  MDUPDATE  -  Maintain  manual  data 

(4)  MDXCHECK.  -  Maintain  exception  checking 

specifications 

(5)  MDCOLLECT  -  Collect  management  data 


V  ' 


Before  programs  are  developed  under  the  PSL  system,  a  user 
establishes  his  project  and  library.  The  following  PSL 
Functions  are  used  for  general  library  maintenance. 


3. 1.1.1  INITIAL 

Under  the  PSL  system,  a  user  stores  programs  and  data  in 
discrete  units,  within  sections  of  a  library,  under  a  project. 

A  project  must  be  initialized  before  libraries  are  built  under 
it.  The  PSL  Function  INITIAL  establishes  the  project  as  a 
PSL  project  and  prepares  an  index  for  library-sections  under 
the  project. 

Example : 

**  INITIAL  PROJECT-FHACD129 

3. 1.1. 2  CREATE 

After  a  project  is  initialized,  the  CREATE  Function  is  used  to 
build  sections  in  the  user's  library.  The  library  name  uniquely 
identifies  a  group  of  standard  sections  under  a  project. 

Example : 

**  CREATE  PROJECT-FHACD129,LIBRARY-NEWCODE, SECTION-SOURCE 

**  CREATE  PROJECT-FHACD129,LIBRARY-NEWCODE, SECTION-OBJECT 

Within  a  library,  the  PSL  system  allows  the  user  to  create  any 
of  the  ten  standard  PSL  sections  and  a  special  program  section: 

a.  SOURCE  —  This  section  contains  all  of  the  source 

code  which  is  stored  in  a  library,  regardless  of  language 
or  structure.  Units  of  structured  code,  which  at  present 
Include  Structured  COBOL  (SCOBOL),  JOVIAL  (SJOVIAL)  and 
Structured  FORTRAN  (SPFORT),  and  units  of  unstructured 
source  code  which  are  processed  by  the  General  Preprocessor 
(see  Appendix  I)  are  stored  in  blocks  within  the  PSL 
standard  file.  It  is  recommended  that  the  size  of 
structured  units  be  restricted  to  one  page  of  code.  For 
compilation,  both  structured  units  and  General  Prepro¬ 
cessor  units  are  combined  in  accordance  with  the 
INCLUDE  statements  found  in  the  units.  Units  of 
unstructured  code  (ASM,  COBOL,  FORTRAN  and  JOVIAL)  are 
stored  ae  complete  compilable  units  in  sequential  files. 
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b.  OBJECT  -  The  object  modules  which  result 
from  compilation  of  source  code  are  recorded  in  the 
OBJECT  section.  The  name  of  the  object  unit  is 

the  same  as  the  name  of  the  top-most  unit  of  source 
code.  Object  modules  are  used  singly  or  in  com¬ 
bination  to  form  a  load  module  for  execution. 

c.  LOAD  -  If  the  load  module  is  to  be  saved 

on  permanent  storage,  it  is  recorded  as  a  system- 
loadable  program  in  the  LOAD  section.  Units  in 

the  OBJECT  and  LOAD  sections  are  produced  by  Sperry 
Univac  system  functions  and  are  therefore  not 
maintained  with  unit  maintenance  Functions,  as  are 
the  other  sections. 

d.  LINK  -  Units  in  this  section  are  used  to 

store  control  cards  for  directing  the  loading 
processing  when  more  than  one  object  module  is  to 
be  loaded . 

e.  JOB  -  Control  cards  may  be  stored  in  units 

in  the  JOB  section  and  invoked  by  the  EXECUTE 
Function.  The  cards  will  be  added  to  the  program 
execution  activity  to  provide  the  job  control 
cards  the  user's  program  requires. 

f.  TEST  -  This  is  a  general  section  for  card- 

format  data  usually  used  for  test  input. 

g.  PDL  -  Program  Design  Language  statements 

are  stored  in  units  in  the  PDL  section.  PDL 
consists  of  English-like  statements  which  follow 
the  basic  rules  of  structured  programming  and  are 
used  to  define  the  program  structure  and  logic. 

h.  TEXT  -  This  section  contains  units  of 

standard  textual  material,  which  are  written 
primarily  for  use  as  program  documentation.  The 
units  may  be  maintained  under  the  PSL  system 
and  printed  as  any  other  card-format  unit. 

i.  USER  -  Units  in  this  section  are  used  to 

store  data  generated  by  non-PSL  functions. 
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j.  MGMT  -  A  mangement  plan  unit  la  initial¬ 

ized  in  the  created  MGMT  aectlon  and  aubaequently 
updated  to  define  the  project  elements  that 
coaprlae  the  management  data  report  requirement. 

Format  unite  are  eatabllahed  to  define  the  report 
contents  and  Input  unite  are  added  to  Introduce 
manual  data.  Both  automatic  data  from  unit  accoun¬ 
ting  records  and  manually  input  data  are  collected 
and  archived  in  collection  unlt8  for  aubsequent 
input  to  management  data  reporta. 

k.  PROGRAM  -  Object  module8  which  have  been 

recorded  in  the  OBJECT  section  are  atored  as  re¬ 
locatable  elements  in  the  PROGRAM  aectlon.  Load 
modules  which  have  been  recorded  in  the  LOAD 
section  are  also  atored  in  the  PROGRAM  section  as 
absolute  modules. 

3. 1 . 1. 3  BACKUP 

The  PSL  system  provides  a  BACKUP  Function  to  save  the  user's 
programs  and  data  on  tape.  The  BACKUP  may  be  invoked  for  a 
complete  project,  a  library,  or  a  section. 

Example : 

**  BACKUP  PROJECT-FHACD129, LIBRARY-NEWCODE, SECTION-ALL 

(tape  identification  required) 

3. 1.1.4  RESTORE 

The  RESTORE  Function  is  used  to  write  the  contents  of  the 
BACKUP  tape  into  the  library.  This  Function  may  be  used  to 
restore  the  complete  contents  of  the  BACKUP  tape,  or  it  may 
selectively  recover  a  portion  of  the  total  data  tape  at  a 
lower  level. 

Examp le : 

**  RESTORE  PROJECT-FHACD129 .LIBRARY-NEWCODE, 

SECTION- SOURCE, UN IT-TIPTOP 

(tape  identification  required) 

3. 1.1. 5  TERMINATE 

This  Function  enables  a  user  to  delete  a  section,  a  library, 
or  an  entire  project.  Files  which  are  released  are  over¬ 
written. 

Example : 

**  TERMINATE  PROJECT-FHACD129 , LIBRARY-NEWCODE , 

**  SECTION-OBJECT 


3.1.2  Unit  Maintenance 


After  a  user  has  Initialized  a  project  and  haa  created  the 
sections  which  are  needed  In  his  library,  data  may  be  stored 
In  these  units.  The  user  may  add  and  update  data  in  those 
sections  which  are  used  for  card-image  data  (SOURCE,  PDL,  LINK, 
JOB,  TEST,  and  TEXT) .  Units  In  the  OBJECT  and  LOAD  sections 
are  not  maintained  directly  by  the  user,  since  they  are 
automatically  created  and  updated  by  the  PSL  system  as  a  result 
of  the  COMPILE  and  LINK  Functions  (see  subsection  3.1.3).  MGMT 
units  are  updated  by  the  management  data  collection  Functions. 
The  user  may  add  and  update  data  created  by  non-PSL  functions  In 
the  USER  section. 

The  PSL  system  automatically  maintains  accounting  information 
for  each  unit  In  each  section.  This  Information  Is  Initialized 
when  the  unit  Is  created  and  updated  when  the  unit  Is  modified. 
The  items  of  accounting  data  for  each  unit  are  shown  In 
Figure  3-01. 

The  following  PSL  functions  are  used  to  add,  change,  and  purge 
units  of  card-image  data  In  sections  (other  than  MGMT)  In  the 
user's  library. 

3. 1.2.1  ADD 

The  ADD  Function  Is  used  for  the  original  Introduction  of  data 
into  a  unit.  The  accounting  Information  for  the  unit  Is  Init¬ 
ialized  by  the  ADD  Function.  The  actual  data  cards  for  the 
new  unit  follow  the  ADD  Function  card  in  the  run  stream. 

Example : 

**  ADD  PROJECT” FHACD 129 , L IBRARY-NEWCODE , 

**  SECTION-SOURCE, UNIT-TIPTOP, 

**  LANGUAGE-SCOBOL 

(user's  source  statements  follow) 

3. 1.2. 2  REPLACE 

After  data  has  been  added  to  a  unit,  the  REPLACE  Function  is 
used  to  completely  replace  all  of  the  data  lines  in  t>..s  unit. 
Accounting  Information  is  not  re-lnltlallzed,  but  is  updated. 

Example : 

**  REPLACE  PROJECT-FHACD129 , LIBRARY-NEWCODE , 

**  SECTION-SOURCE, UNIT-TIPTOP 

(user's  source  statements  follow) 


Accounting  Information  in  First  Data  Block 


Accounting  Record 
Unit  type 

Including  unit  name 

Version  number 

Modification  level 

Date  unit  vas  originated 

Name  of  originator 

Date  of  last  update 

Time  of  last  update 

Name  of  update  programmer 

Unit  key 

Unit  language 

Number  of  times  included 

Number  of  lines  in  unit 

Extended  Accounting  Record 

Number  of  lines  added 

Number  of  lines  changed 

Number  of  lines  deleted 

Total  number  of  lines  input  to  unit 

Number  of  lines  input  in  this  cycle 

Number  of  lines  copied  to  unit 

Number  of  times  unit  vas  compiled  (top) 

Total  number  of  updates  to  unit 

Number  of  updates  to  unit  in  this  cycle 


Figure  3-01.  Accounting  Information  for  a  Unit 
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Accounting  Information  for  Management  Data  Units 


Accounting  Record 
Unit  type 

Verification  status 

End  of  cycle  switch 

Archive  Indicator 

Start  date  of  cycle 

End  date  of  cycle 

Cycle  period 

Cycle  count 

Archive  count 

Unit  level  name 

Version  name 

Modification  number 

Date  unit  was  originated 

Name  of  originator 

Date  of  last  update 

Time  of  last  update 

Name  of  update  programmer 

Unit  key 

Unit  language 

Number  of  times  INCLUDED 

Number  of  lines  in  unit 


Figure  3-01.  Accounting  Information  for  a  Unit 
(Continued) 
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3. 1.2. 3  CHANGE 


The  CHANGE  Function  Is  used  to  modify  the  contents  of  a  unit. 
Modification  details  are  provided  on  Subfunction  cards  (COPY, 
DELETE,  INSERT,  MODIFY,  and  SHIFT)  which  follow  the  CHANGE 
card.  New  source  statements  follow  the  INSERT  and  MODIFY 
Subfunction  cards. 

Example : 

**  CHANGE  PROJECT  FHACD129 , LIBRARY-NEWCODE , 

**  SECTION-SOURCE , UNIT-TIPTOP 

**  COPY  AFTER-0 .OLDU-ADUN , OLDPRO J-FHACD14 7 , 

FROM-  (1,10) , 

**  SHIFT  LINE-(1,4) , C0LUMN-R5 

**  MODIFY  LINES- (5,9) 

(new  data  inserted  here) 

**  DELETE  LINES- (11 ,12) 

**  INSERT  AFTER-13 

(new  data  Inserted  here) 

**  MODIFY  LINE- (14 ,18) , FROM-MOVETO , TO»"MOVE" 

3. 1.2. 4  MOVE 

Units  are  moved  from  one  library  to  another,  or  within  a 
library,  with  the  MOVE  Function. 

Example : 

**  MOVE  PROJECT-FHACD147 .LIBRARY-PROVEN, 

**  OLDPRO J-FHACD129 , OLDLIB-NEWCODE , 

**  SECTION-SOURCE , UNIT-TIPTOP 

3. 1.2.5  PURGE 

An  individual  unit  is  removed  from  a  library  with  the  PURGE 
Function.  A  user  should  be  aware  that  units  are  also  removed 
from  a  library  when  a  higher  aggregation,  such  as  a  section 
or  library,  is  removed  with  the  TERMINATE  Function. 

Example : 

**  PURGE  PROJECT-FHACD129 .LIBRARY-NEWCODE, 

**  SECTION-SOURCE , UNIT-TIPTOP 

If  the  PURGE  of  a  unit  results  in  the  release  of  a  file,  the 
file  contents  will  be  overwritten.  See  subsection  3.4.22 
(PURGE) . 


The  PSL  system  provides  many  facilities  to  support  the  compila¬ 
tion,  loading,  and  execution  of  programs.  One  of  the  more 
powerful  capabilities  available  for  these  Functions  is  the 
optional  search  through  multiple  libraries  during  retrieval. 

This  option  is  Illustrated  under  the  appropriate  Functions  in 
subsection  3.4.  In  this  subsection  each  of  the  three  program 
processing  Functions  is  presented  in  its  most  straightforward 
form. 

3 . 1 . 3 . 1  COMPILE* 

The  COMPILE  Function  retrieves  units  from  the  SOURCE  section, 
Invokes  the  appropriate  precompiler  for  structured  source  code, 
compiles  (or  assembles)  the  resulting  stream  of  code,  records 
the  unit  in  the  OBJECT  section,  and  stores  the  compiled  source 
as  a  relocatable  element  in  the  PROGRAM  section.  The  UNIT  name 
is  the  name  of  the  top-most  source  unit  of  the  module  which  is 
to  be  compiled.  This  name  will  be  used  for  the  name  of  the 
compiled  OBJECT  unit.  The  processing  which  is  Invoked  by  the 
COMPILE  Function  depends  upon  the  language  of  the  unit.  Under 
the  present  PSL  system,  procedures  exist  to  process  languages 
ASM,  ASMG  (compacted  ASM),  COBOL,  COBOLG  (compacted  COBOL), 

SCOBOL  (Structured  COBOL),  FORTRAN,  FORTRANG  (compacted  FORTRAN), 
SPFORT  (Structured  FORTRAN),  JOVIAL,  JOVIALG  (compacted  JOVIAL), 
and  SJOVIAL  (Structured  JOVIAL). 

Example : 

**  COMPILE  PROJECT-FHACD147 ,  LIBRARY-NEWCODE , UNIT-TIPTOP 

3.  1.3.2  LINK 

The  LINK  Function  retrieves  one  or  more  object  module  entries 
from  the  OBJECT  section,  collects  the  corresponding  relocatable 
elements,  and  records  the  new  absolute  element  in  the  LOAD 
section.  The  resulting  absolute  element  is  stored  as  a  unit  in 
the  PROGRAM  section. 

Example : 

**  LINK  PROJECT-FHACD147 .LIBRARY-NEWCODE, LINE-TIPTOP 

If  more  than  one  object  module  is  to  be  linked  together  to  form 
the  load  module,  collector  control  cards  are  retrieved  from  a 
unit  in  the  LINK  section.  This  option,  and  others,  are  explained 
under  the  LINK  Function  in  subsection  3.4.13. 


*Also  see  Appendix  I. 


3. 1.3. 3  EXECUTE 


The  user's  Job  control  cards  for  execution  of  his  programs  are 
previously  stored  as  a  unit  in  the  JOB  section.  The  EXECUTE 
Function  invokes  the  execution  of  his  program  using  these  job 
control  cards  as  his  input  run  stream. 

The  program  itself  may  be  retrieved  by  the  PSL  system  in  one 
of  the  following  forms: 

a.  A  load  module  from  the  PROGRAM  section 

b.  A  series  of  one  or  more  object  modules  which  are 
selected  as  a  result  of  collector  control  cards  in 
a  unit  of  the  LINK  section  and  which  will  be 
processed  by  the  Collector. 

Example : 

**  EXECUTE  PROJECT-FHACD147 , LIBRARY-NEWCODE , 

**  JOB-MYJCL, LINK-TIPTOP 

See  subsection  3.4  for  a  more  detailed  explanation. 


3.1.4  Output  Processlnt 


Six  PSL  Functions  are  available  in  the  PSL  system  to  obtain 
reports . 


3. 1.4.1  INDEX 


The  INDEX  Function  prints  a  status  report  for  a  section.  The 
report  contains  information  pertaining  to  the  section  as  a 
whole,  as  well  as  a  listing  of  the  index  for  the  section.  An 
example  of  a  Section  Index  Report  is  shown  in  Figure  3-02. 


Example : 

**  INDEX  PROJECT-FHACD147 .LIBRARY-NEWCODE .SECTION-SOURCE 


3. 1.4. 2  SOURCE 

The  SOURCE  Function  can  be  used  to  print  a  listing  of  any  unit 
which  is  in  card-image  format.  This  includes  the  units  in 
the  SOURCE,  PDL,  LINK,  JOB,  MGMT ,  TEST,  and  TEXT  sections.  If 
the  unit  is  from  the  SOURCE  or  the  PDL  section  and  the  unit  is 
written  in  a  supported  structured  language  (Structured  COBOL, 
JOVIAL  and  FORTRAN),  the  structured  code  is  automatically 
Indented  for  the  proper  alignment  of  the  structures  on  the 
listing.  This  listing  is  always  provided  when  a  unit  is  added 
to  the  library  or  modified.  The  contents  of  the  unit  may,  on 
option,  be  written  to  tape  or  punched  on  cards.  In  these  latter 
cases,  the  header  information  is  omitted  and  the  code  is 
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reproduced  as  it  exists  in  the  unit,  without  automatic 
indentation.  An  example  of  a  listing  of  structured  COBOL 
(SCOBOL)  is  shown  in  Figure  3-03. 

Example : 

**  SOURCE  PROJECT-FHACD129 .LIBRARY-NEWCODE, 

**  SECT ION- SOURCE , UNIT-TIPTOP-PROCEDURE-DIVI SION 

3. 1.4. 3  MDPRINT 

The  MDPRINT  Function  is  used  to  print  management  data  reports. 
There  are  two  categories  of  such  reports: 

a.  Program  Structure  Report 

b.  Management  Data  Report 

The  Program  Structure  (PS)  report  begins  with  the  unit  which  is 
named  on  the  Function  card  and  develops  a  hierarchically  nested 
and  indented  list  of  all  units  which  are  referenced  by  or  in 
units  which  are  themselves  INCLUDEd  in  the  hierarchical  program 
structure.  Units  which  are  referenced  by  a  CALL  statement  are 
also  printed  with  the  appropriate  indentation  in  the  list,  but 
they  are  not  automatically  searched  for  lower  levels  of  INCLUDE 
or  CALL  statements.  An  option  is  available  to  invoke  a  PS  report 
for  all  CALLed  units.  Statistical  organization  information  is 
printed  for  each  unit.  An  alphabetically-arranged  list  of  all 
referenced  units  follows  the  hierarchical  list.  An  example  of  a 
Program  Structure  Report  is  shown  in  Figure  3-04. 

Example : 

**  MDPRINT  PROJECT-FHACD129 , LIBRARY-NEWCODE , 

**  UNIT-TIPTOP  .REPORT-PS 

A  Management  Data  report  prints  the  contents  of  one  or  more 
management  data  units.  The  top-level  unit  is  identified  by  the 
UNIT  keyword.  Management  data  units  may  contain  a  combination  of 
automatically  collected  data  and  manually  input  data  combined 
according  to  the  specifications  in  an  associated  user-defined 
format  unit.  A  general  format  is  provided  to  accommodate  a  wide 
variety  of  data  collections  to  be  printed.  A  representative 
Management  Data  Report  is  shown  in  Figure  3-05. 

Example : 

**  MDPRINT  PROJECT-FHACD129, LIBRARY-NEWCODE, 

**  UNIT-TIPTOP, REPORT-MD 
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3. 1.4.4  AUTHOR 


.. :*>;  v&*~.  t  ■ '  r»f 7  :2fT*  *»*^  * 


The  AUTHOR  Function  can  be  used  to  print  a  list  of  unit 
naaesi  or  listings  of  the  actual  units,  which  vere  originally 
generated  by  and/or  updated  by  a  specific  programmer.  An 
example  of  an  AUTHOR  Report  is  shown  In  Figure  3-06. 

Example : 

**  AUTHOR  PROJECT-FHACD129 .LIBRARY-NEWCODE , 

**  SECTION-SOURCE  , UP GMR- SMITH  .OPTION- SOURCE 

3. 1.4. 5  DOCUMENT 

The  DOCUMENT  Function  is  used  to  print  documentation  stored  In 
a  library  in  the  form  of  program  design  language,  structured 
source  code,  text,  etcetera.  Output  requirements  are  specified 
through  keyword  options  provided  on  subfunction  cards  (HEADER, 
TEXT,  EJECT,  and  SPACE).  An  example  of  a  DOCUMENT  Report  is 
shown  in  Figure  3-07. 


Example : 

aa 

DOCUMENT 

PRO J-FHACD129 , LIB-NEWCODE , 

** 

SECTION-SOURCE 

** 

HEADER 

THIS  IS 

A  HEADER  CARD 

** 

TEXT 

UNIT-FIRST-UNIT 

** 

SPACE 

LINES-6 

.  ** 

TEXT 

THIS  IS 

CARD  1  OF  2 

THIS  IS 

CARD  2  of  2 

A  A 

EJECT 

A  A 

TEXT 

UNIT-LAST-UNIT 

3. 1.4. 6 

CSCAN 

The  CSCAN  Function  Is  used  to  scan  all  units  of  the  Indicated 
section  to  locate  a  specific  character  string.  The  string 
may  be  up  to  48  characters  in  length.  The  resulting  output 
will  be  a  list  of  the  unit  names  containing  the  specific 
character  string  and  the  corresponding  lines  of  code  for  each 
occurrence.  Figure  3-08  contains  an  example  of  character  scan 
output . 

Example : 

**  CSCAN  PROJ-FHACD129 , LIBR-NEWCODE , 

**  SECTION-JOB, STRING-TIPTOP 
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*  THE  MODULE  TIPTOP  PROCESSES  THE  ADD  A  UNIT  FUNCTION  (ADUN) 
TIPTOP 

INITIALIZE  PARAMETER-TABLE  WITH  SPACES 
CALL  OBUS 

MOVE  PGMR-NAME  TO  PARAMETER-TABLE 
OPEN  INPUT  INPUT-CARDS. 

OUTPUT  MESSAGE-FILE 
MOVE  "ADD"  TO  INPUT-FUNCTION 
READ  INPUT-CARDS 
IF  NOT  END  OF  INPUT  CARDS 
CALL  OBFN. 

DO  UNTIL  NORMAL  RETURN  FROM  OBFN 
SEARCH  PSL- FUNCTIONS 

WHEN  PSL-FUNCTION  IN  THE  TABLE  EQUAL  INPUT-FUNCTION 
SET  FUNCTION-NUMBER  TO  INDEX  OF  TABLE. 

INCLUDE  PROCESS-FUNCTION. 

CALL  OBFN , 

ENDDO. 

CALL  PRINT  MESSAGE  (END  OF  INPUT  CARDS). 

IF  SPAWN  JOB  NEEDED 
INCLUDE  SPAWN-A-JOB 
END IF. 

ELSE 

CALL  PRINT  MESSAGE  (NO  INPUT  CARDS) 

ENDIF. 

CALL  RLAF. 

CLOSE  INPUT-CARDS. 

MESSAGE-FILE . 

STOP  RUN. 


Figure  3-07.  DOCUMENT  Report 
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3.1.5  General  Functions 

Two  PSL  Functions  are  available  which  have  general  application 
in  conjunction  with  other  Functions. 

3. 1.5.1  PARAM 

This  Function  is  used  to  enter  high-level  parameters  which 
apply  to  a  series  of  subsequent  Functions.  The  particular 
parameters  which  may  appear  on  a  PARAM  card  (PROJECT,  LIBRARY, 
SECTION,  PASSWORD,  and  PGMR)  are  cumulative  parameters.  When 
any  of  these  parameters  are  established,  it  remains  in  effect. 

A  PARAM  Function  card  is  ordinarily  used  to  establish  these 
values,  but  the  keywords  may  be  established  by  Function  cards 
for  which  they  are  valid  parameters. 

Example : 

**  PARAM 
**  CREATE 
**  ADD 

(user ' s  source 

3. 1.5. 2  JCL 

The  JCL  Function  enables  the  user  to  introduce  JCL  cards  into 
the  input  stream  of  a  subsequently  spawned  job.  The  Function  is 
not  required  in  the  basic  use  of  the  PSL  system,  but  provides  the 
flexibility  of  using  additional  Exec  8  control  cards  in  conjunction 
with  such  PSL  Functions  as  COMPILE  and  LINK.  See  subsection  3.2 
for  a  discussion  of  spawned  jobs  and  subsection  3.4.12  for 
specific  examples  of  the  use  of  this  Function. 

3.1.6  Management  Data  Collection 

This  section  contains  an  overview  of  the  management  data  collection 
capability;  this  overview  is  intended  to  simply  acquaint  the  user 
with  the  capability.  The  types  of  units  which  are  contained  in  a 
Management  (MGMT )  section  are  identified.  The  possible  levels 
for  which  management  data  can  be  collected  and  reported  are 
introduced.  The  actions  necessary  to  perform  a  data  collection 
are  briefly  described. 


PROJECT-FHACD147 , LIBRARY-NEWCODE 
SECTION-SOURCE 
UNIT-TIPTOP , LANGUAGE- SCO BOL 
data  cards) 
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General  Overview 

The  Management  Data  Collection  and  Reporting  (MDCR)  capability 
enables  software  projects  utilizing  the  PSL  facility  to  obtain 
statistical  data  reports  on  the  status  and  progress  of  project 
activities.  Figure  3-09(a)  illustrates  a  typical  MDCR  Data 
Base  composed  of  a  single  Management  (MGMT)  section  library  and 
multiple  Source  section  libraries.  The  set  of  top  units  and 
included  units  presented  in  these  libraries  constitutes  the 
total  code  under  development  for  a  given  project.  Statistics 
relating  to  unit  update  activity  are  maintained  in  the 
individual  Unit  Accounting  records  (refer  to  Figure  3-01  for  a 
list  of  statistics  maintained).  These  “automatic"  statistics 
may  be  collected  and  summarized  as  directed  by  the  PSL  user 
through  Management  Data  Functions  made  available  with  the  MDCR 
capability. 

The  PSL  MGMT  section  shown  in  Figure  3-09  (a)  provides  storage 
for  the  management  data  units  that  direct  the  MDCR  activities. 

The  MDPLAN  Function  is  first  utilized  to  describe  the  hierarchical 
organization  of  data  reports  whose  generation  is  illustrated  in 
Figure  3-09  (b).  The  MDPLAN  input  is  made  in  the  form  of  keyword 
and  keyword  value  specifications  which  are  ordered  to  reflect  the 
subordinate  relationships  that  are  observed  in  producing  data 
summaries.  The  hierarchy  of  data  reports  shown  in  Figure  3-09  (b) 
as  a  result  of  the  given  plan  input. 
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data  to  be  reported  at  each  level  of  output 
provided  to  the  MDFORMAT  Function.  An 
be  established  and  updated  for  each  of  the 
escribed  in  the  management  data  plan  to 
source  of  data  items  to  be  collected  and 
vel  format  may  optionally  be  pro  sided  to 
ed  unit  accounting  record  data  to  be 
liable  for  output  in  conjunction  with  the 
el  elements  specified  in  the  management  data 


Module  level  data  may  be  derived  from  essentially  two  data  sources; 
that  is,  1)  unit  accounting  records,  and  2)  manual  inputs.  The 
latter  source  of  data  input  is  established  through  the  MDUPDATE 
Function  by  adding  a  management  input  unit  with  the  same  name  as 
the  plan  element  (e.g.,  module  level  element)  with  which  the  data 
is  to  be  corresponded.  The  module  level  format  unit  would  in 
turn  prescribe  that  specific  data  items  in  the  module  report  are 
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Applicable 
PSL  Functions 


*  PSL  MCMT  Section 


•k  *  -k  ic 


Management  Data  Plan  Unit  (MDCR-PLAN) 


SYSTEM  =  BIGTOP 
JOB  =  BIGJOB 

SUBSYS=SUB1,  MODULE=MODlA ,  MODULE =MOD IB 
SUBSYS=SUB2,  MODULE =MOD2 A,  MODULE =MOD2B 


Management  Data  Format  Units  (MDCR- FORMAT-) 


SYSTEM 

SUBSYS 

MODULE 

JOB 

UNIT  ^ 

| 

1  * 

Management  Data 

Input  Units 

*.  ! 

MDUPDATE 

MDXCHECK 


BIGTOP  |  BIGJOB  I  S 


MDCOLLECT 

PURGE 


Management  Data  Collection  Units 


MDCR- COLLECT I ON  MDCR- ARCHIVE-001- (DATE1) 

MDCR-ARCHIVE-002- ( DATE 2 ) 
MDCR-ARCHIVE-00  3- ( DATE  3) 


******  PSL  SOURCE  Section (s)  ****** 


Included  Units 


Top  Units 

ADD 

CHANGE 

MOD  1A 

MOVE 

MOD  IB 

REPLACE 

MOD  2  A 

PURGE 

MOD  2B 

Figure  3-09 (a) .  Management  Data  Base  Structure 
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Management  Plan  Input 


vs  . 


Management  Reports  Output 


System  -  PSL-project 

Job  “  PSL-system-test 
Subsystem  •  PSL-main 
Module  -  BCTLE 
Module  -  PPLK.E 


Subsystem 
Module  “ 
Module  ■ 
Module  ■ 


PSL-Function 

ADUNE 

CHUNE 

CRFLE 


Subsystem  -  PSL-auxIliary 
Module  -  ADXEE 
Module  -  CHXXE 


Figure  3-09(b).  Management  Report  Structure 
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to  be  derived  from  a  manual  data  source.  These  Items  are 
looked  for  (whenever  module  data  is  collected)  in  a  manage¬ 
ment  input  unit  vhoae  name  corresponds  with  the  module  being 
processed.  Provision  of  such  data  is  optional;  "null" 
values  will  be  reported  in  the  absence  of  available  data. 

Job  level  elements  (whose  input  is  currently  derived  from 
manual  data  sources  only)  may  be  used  to  introduce  computer 
utilization  statistics  (or  other  pertinent  data)  into  the 
reported  output.  Subsystem  level  data  may  be  derived  from 
subordinate  module  and/or  job  level  data  items  and  a 
corresponding  management  input  unit.  The  subsystem  level 
format  reflects  the  data  source  of  each  item  listed  and  may 
specify  the  type  of  summarization  to  be  performed.  (Refer 
to  paragraph  3.4.15  for  further  details).  The  system  level 
format  unit  may  specify  that  data  be  derived  from  subordinate 
subsystem,  module  and/or  job  level  data  items  as  well  as 
corresponding  manual  data  sources. 

Management  input  units  established  via  the  MDUPDATE  Function 
may  also  be  used  to  maintain  exception  check  specifications 
through  use  of  the  MDXCHECK  Function.  Any  two  numeric  data 
items  specified  in  the  corresponding  level  format  unit  may 
be  subjected  to  a  value  "variance"  check.  The  data  item 
values  are  compared  at  the  time  the  data  is  collected  and  a 
determination  made  as  to  whether  an  exception  exists.  If 
an  exception  does  exist,  pertinent  information  is  added  to 
the  data  collection  unit  so  that  management  reports  which  are 
subsequently  produced  from  that  collection  may  flag  the 
excepted  data  item. 

The  MDCOLLECT  Function  performs  a  data  collection  when  directed 
to  a  project  MGMT  section  containing  an  appropriate  management 
data  plan.  The  ensuing  collection  activity  automatically 
verifies  and  cross-relates  plan  level  elements,  format 
requirements  and  data  source  availability.  If  no  significant 
error  (e.g.,  absence  of  a  required  format  or  a  plan  syntax 
error)  is  determined,  the  data  sources  indicated  in  the 
management  data  plan  and  format  units  will  be  searched. 

Source  code  modules  (i.e.,  top  units)  which  are  not  found 
will  be  noted  as  errors,  but  data  collection  will  proceed 
until  the  entire  management  plan  is  processed  and  the 
collected  data  is  stored  in  the  designated  MGMT  section. 

If  a  previous  data  collection  exists,  it  will  be  replaced 
or  archived  based  upon  an  "automatic"  archive  determination 
or  user-specification  of  a  "manual"  archive  option  in  con¬ 
junction  with  the  MDCOLLECT  Function.  (Refer  to  paragraph 
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3.2.10  for  a  more  detailed  discussion  of  automatic  and  manual 
archive  determinations).  Each  archived  data  collection  Is 
named  with  a  unique  aerial  number  and  date-of-collection 
suffix  as  indicated  in  Figure  3-09 (a). 

Special  Features 

More  than  one  report  hierarchy  may  be  specified  in  the 
management  data  plan.  Each  report  hierarchy  (starting  with 
a  unique  system  level  element)  will  be  processed  in  the 
sequence  that  it  occurs  in  the  management  plan.  Alternative 
aggregations  of  modules,  job  and  subsystems  may  be  reviewed 
in  reported  outputs.  It  must  be  noted,  however,  that 
multiple  (or  repeated)  inclusions  of  given  plan  level 
elements  (e.g.,  a  given  module  may  be  included  in  two 
different  subsystems)  will  be  processed  in  a  special  manner. 
That  is,  the  data  first  collected  for  the  given  element  will 
be  re-utilized  as  input  to  required  summarizatlons  at 
superior  levels  in  the  report  hierarchy.  Output  of  the  given 
report  element  Itself  will  be  made  in  association  with  its 
first  occurrence  only. 

If,  for  example,  a  given  subsystem  element  were  included  in 
two  different  system  hierarchies,  the  subsystem  hierarchy 
should  be  specified  in  connection  with  its  first  occurrence. 
Any  redefinition  of  that  subsystem  hierarchy  (in  subsequent 
occurrences)  will  be  noted  (with  advisory  messages)  and 
processing  will  continue  as  if  such  redefinition  were  not 
present.  The  occurrence  of  repeated  inclusions  of  a  given 
plan  level  element  also  causes  advisory  messages  to  be 
generated  so  that  the  user  can  take  corrective  action  if  the 
repeated  inclusion  is  inadvertent. 

It  will  be  noted  in  Figure  3-09  (a)  that  the  PURGE  Function  is 
applicable  to  all  collected/archived  units.  The  actual  names 
of  the  archived  units  are  determined  by  the  unique  serial 
number  and  date  of  collection  so  that  reference  should  be 
made  to  the  MGMT  section  index  (by  using  the  INDEX  Function) 
for  a  specific  listing  of  archive  unit  names.  The  PURGE 
Function  is  not  applicable  to  any  other  units  in  the  MGMT 
section  since  both  format  units  and  management  input  units 
may  be  deleted  via  the  MDFORMAT  and  MDUPDATE  Functions, 
respectively.  The  management  plan  unit  (having  been  added  by 
the  CREATE  Function)  is  not  deleted  until  the  MGMT  section  is 
terminated . 
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MDCR  Function* 


When  data  has  been  collected,  a  management  report  la  generated 
when  an  MDPRINT  Function  with  the  REPORT-MD  option  la 
requested.  The  management  data  report  has  a  general  format 
which  provides  appropriate  Identification  of  the  level  of  data 
and  the  specific  Items  for  which  values  are  printed.  Figure 
3-05  contains  a  sample  management  data  report. 

The  management  data  collection  capability  consists  of  five 
special  Functions  as  well  as  support  from  previously  described 
Functions.  This  set  of  capabilities  enables  PSL  users  to 
design  management  data  collections  to  reflect  the  needs  of  a 
specific  project. 

The  special  Functions  which  provide  the  data  collection 
capability  are  described  In  the  following  paragraphs. 

3. 1.6.1  MDPLAN 

The  Management  Data  Plan  Function  Is  used  to  define  the 
management  data  report  structure.  The  plan  unit  (without  data 
contents)  is  added  automatically  when  a  MGMT  section  is 
created.  The  MDPLAN  Function  is  then  used  to  modify  the 
contents  of  the  plan  unit. 

Example : 

**  CREATE  PROJ-PHACD129 , LIBR-NEWCODE , 

**  SECTION-MGMT 

**  MDPLAN 

(subfunction  and  source  cards  to  modify  the  plan) 

3.1.6. 2  MDFORMAT 

The  Management  Data  Format  Function  Is  used  to  define  the  data 
items  that  may  be  reported  at  the  five  record  levels  previously 
described.  Both  automatically  collected  data  Items  and 
manually  Input  data  Items  may  be  defined.  Format  units  can  be 
added,  changed,  or  deleted  by  MDFORMAT  as  required. 

Example : 

**  MDFORMAT  PRO J-FHACD1 2 9 , LIBR-NEWCODE , 

**  OP-ADD .LEVEL-SYSTEM 

(source  cards) 
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3. 1.6.3  MDUPDATE 


The  Management  Data  Update  Function  Is  used  to  maintain  the 
manually  provided  data  which  resides  in  management  data  units 
This  data  can  be  added,  changed,  or  deleted  as  required. 

Example : 

**  MDUPDATE  PROJ-FHACD129 , LIBR-NEWCODE , 

**  UNIT-TIPTOP .OP-ADD  , 

**  LEVEL-SYSTEM 

(source  data  cards) 

3.1.0. A  MDXCHECK 

The  Management  Data  Exception  Checking  Function  is  used  to 
annotate  "excepted"  data  values  in  a  management  report. 
Exception  check  specifications  are  maintained  in  a  management 
data  unit  corresponding  to  a  denoted  element  in  the  report 
structure  (i.e.,  plan  unit).  The  specifications  reference 
numeric  data  items  contained  in  the  associated  record  level 
format . 

Example : 

**  MDXCHECK  PROJ-FHACD129, LIBR-NEWCODE, 

**  UNIT-TIPTOP 

(subfunction  and  data  cards) 

3. 1.6. 5  MDCOLLECT 

The  Management  Data  Collection  Function  is  used  to  collect 
and  archive  the  data  designated  by  MDPLAN,  MDFORMAT,  MDUPDATE 
and  MDXCHECK.  Recycling  of  cyclic  data  accumulations  and 
archiving  data  are  options  of  the  MDCOLLECT  Function. 

Example : 

**  MDCOLLECT  PROJ-FHACD129 , LIBR-NEWCODE , 

**  ARCHIVE-YES .RECYCLE-NO 
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The  example  ahown  In  Figure  3-09  (c)  repreaents  a  typical 
"off-the-cuff"  appllcatlou  of  MDCR  Functions  to  obtain 
management  statistics  on  newly  developed  code  In  the  system 
project  PSLPRG  library.  A  management  section  Is  first  created 
to  accommodate  units  to  be  added  and  updated  by  the  MDCR 
Functions.  The  MDCR-PLAN  unit  Is  updated  to  delineate  the 
modules  whose  source  code  statistics  are  to  be  collected  and 
reported.  The  PSL  modules  which  constitute  the  newly  developed 
code  are  aggregated  under  a  subsystem  element  named  NEWCODE  and 
the  project  and  library  in  which  the  source  code  statistics  are 
maintained  Is  designated.  Management  data  format  units  are 
then  added  for  the  planned  report  levels.  Module  level  format 
items  are  specified  according  to  guidance  given  in  Figure  3-13. 
Output  labels  are  provided  to  fully  describe  the  items  being 
reported  (beginning  in  column  25)  and  a  reference  to  the 
associated  data  or  special  item  statistic  is  made  (in  columns 
5  through  8)  as  directed  by  Table  3-2.  Subsystem  level  format 
items  are  specified  with  reference  to  numeric  data  Items 
collected  at  the  module  level.  The  special  item  referenced 
(i.e.,  number  of  modules)  is  calculated  during  management  data 
collection  operations  as  invoked  by  the  MDCOLLECT  Function. 

Using  the  MDCR-PLAN  unit  and  MDCR-FORMAT  units  as  directive 
inputs,  the  MDCOLLECT  Function  operates  to  retrieve  the  required 
unit  statistics  and  to  summarize  those  statistics  at  the  module 
and  subsystem  levels.  The  collected  statistics  are  stored  in 
the  MDCR-COLLECTION  unit  for  input  to  the  Management  Data  (MD) 
Report  invoked  by  the  MDPRINT  Function.  The  MD  report  prints 
out  the  collected  statistics  beginning  with  module  level  data 
and  ending  with  a  subsystem  level  summary. 

The  data  collection  and  reporting  Initiated  in  the  preceding 
example  may  be  readily  extended  to  Include  manual  data  by 
additionally  defining  such  manually  Input  Items  at  the  subsystem 
level,  for  example,  and  adding/updating  a  management  data  Input 
unit  through  the  MDUPDATE  Function  as  follows: 

**  MDFORMAT  PRO J-MYUMC , L IBR-MYLIB , LEVEL-SUBSYS 

**  i 

015  RPTA05MNAME  MODULE  NAME 

**  MDUPDATE  OP-ADD, LEVEL-SUBSYS , UNIT-NEWCODE 
MNAME-PFJ  BE 
MNAME-PCMLE 
MNAME-PP JVE 
MNAME-PRJVE 
MNAME-PPGLE 


**  PARAM  PROJ-MYUMC .LIBR-MYLIB , SECT-MGMT 
**  CREATE  FMS- (20,20) 

**  MDPLAN 
**  I  A-0 

PROJ-SYSUMC,LIBR-PSLPRG 

SUBSYS-NEWCODE 

MODULE-PFJBE 

MODULE-PCMLE 

module-ppjve 


MODULE-PRJVE 

MODULE-PPGLE 

**  MDFORMAT  OP-ADD, LEVEL-MODULE 
010A303  NAME  OF  ORIGINATOR 

020A301  TOP  UNIT  TYPE 

030A302  DATE  TOP  UNIT  ORIGINATED 

040A30A  TOP  UNIT  LANGUAGE 

050A305  DATE  MODULE  LAST  UPDATED 

060$001  NUMBER  OF  UNITS 

070A101  TOTAL  LINES  OF  SOURCE  CODE 

**  MDFORMAT  OP-ADD , LEVEL-SUBSY S 
010$00I  NUMBER  OF  MODULES 

020M070  TOTAL  LINES  OF  MODULE  CODE 

030M070MAX  LARGEST  MODULE  LINES  OF  CODE 

040M060  TOTAL  NUMBER  OF  UNITS 

MDCOLLECT 

**  MDPRINT  REPORT-MD 


Figure  3-09(c).  MDCR  Application  Example 
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A  "repeated"  manual  input  Item  format  specification  ia  Inserted 
into  the  previously  added  subsystem  level  format  unit  following 
item  010  (number  of  modules}.  A  management  data  input  unit 
named  NEWCODE  is  added  and  updated  with  free-formatted  source 
data  specifying  the  item  name  and  item  value  for  each  item 
updated.  The  subsystem  level  format  is  referenced  to  verify 
and  edit  the  input  item  whose  RPT  specification  permits 
multiple  (or  repeated)  values  to  be  provided  and  stored  for  the 
given  item.  An  edit  check  for  an  alphabetic  input  of  five 
characters,  maximum  is  made.  Each  stored  input  value  is 
further  identified  with  a  determined  sequence  number  (shown 
in  the  subsequently  output  "source  data"  listing  for  that  unit) 
for  use  in  deleting  or  changing  particular  item  values  in 
subsequent  manual-item  updates. 

If  the  source  code  being  subject  to  management  data  collection 
and  reporting  were  under  development,  it  would  be  particularly 
appropriate  to  utilize  the  MDXCHECK  Function  for  making  auto¬ 
matic  checks  on  the  progress  of  that  development.  For  example, 
the  number  of  real  units  might  be  compared  with  the  total 
number  of  units  (l.e.,  real  plus  stub  units)  present  in  PSL 
storage.  Since  the  subsystem  format  already  contains  a 
reference  to  the  "total  number  of  units",  only  a  reference  to 
the  number  of  real  units  need  be  added.  This  would  be  done  as 
follows : 

**  MDFORMAT  PRO J-MYUMC , LIBR-MYLIB , LEVEL-MODULE 

I065A202  NUMBER  OF  REAL  UNITS 

**  MDFORMAT  LEVEL-SUBSYS 

I050M065  UREAL  NUMBER  OF  REAL  UNITS 

M040M060  UTOTAL  TOTAL  NUMBER  OF  UNITS 

The  needed  item  must  be  Inserted  in  the  module  level  report 
format  so  that  it  may  be  referenced  by  and  summarized  at  the 
subsystem  level.  The  needed  subsystem  format  item  is  Inserted 
and  a  previously  defined  item  is  modified  to  provide  an  item 
name  for  mnemonic  reference.  An  exception  check  specification 
may  be  provided  immediately  following  the  above  such  as  follows: 

**  MDXCHECK  UNIT-NEWCODE 

**  i 

UREAL  UTOTAL:V20 ,110177 .MANAGEMENT  ACTION  REQUIRED 

This  exception  check  is  inserted  into  the  management  input  unit 
named  NEWCODE  previously  added  through  the  MDUPDATE  Function. 

The  exception  specification  is  verified  against  the  subsystem 
level  report  format  through  correspondence  with  the  item  name 
entries.  The  exception  check  itself  is  performed  when  the 
MDCOLLECT  Function  is  next  invoked.  The  specification  submitted 
is  interpreted  as  follows. 
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If  che  number  of  real  units  Is  less  Chan  Che  total  number  of 
units  wit*-  a  variance  of  twenty  percent  or  more  on  or  after 
November  1977,  the  message  "management  action  required" 
will  be  given. 

The  message  will  follow  the  line  which  reports  the  number  of 
real  units  and  will  specify  the  computed  variance  and  identify 
the  item  number  of  the  item  to  which  the  number  of  real  units 
Is  being  compared.  Since  each  reported  item  is  identified  by 
item  number  as  well  as  item  name  and  output  label,  the 
reference  to  the  compared  item  number  may  be  readily  related 
to  the  "total  number  of  units"  item  in  that  same  subsystem 
level  report.  The  exception  check  may  then  be  verified  by 
an  "on-the-spot"  comparison  of  the  two  item  values. 

This  concludes  the  example  of  MDCR  Function  utility  in  a 
typical  management  data  collection  and  reporting  application. 
Familiarity  gained  with  the  MDCR  facility  through  initial 
application  will  confirm  the  PSL  capability  to  collect  and 
report  management  data  statistics.  The  MDCR  Functions  may 
subsequently  be  applied  to  satisfy  evolving  management  require¬ 
ments  by  providing  pertinent  and  timely  information  on  the 
status  and  progress  of  software  development  activities. 
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3 . 2  Composition  Guides 


The  PSL  system  is  initialized  in  the  user's  run  stream  by  -hc 
following  card : 

Col 

1 

@US  E  PSL.  , DMA*  P  S  L . 

@ ADD  PSL. RUN 

Following  the  @ADD  card,  one  or  more  PSL  Function  cards 
are  used  to  direct  the  PSL  system  to  perform  the  desired 
processing.  If  user  data  cards  are  appropriate  for  a 
particular  Function,  they  are  inserted  immediately  after  the 
associated  Function  card.  Specific  Function  formats  and 
examples  of  their  use  are  given  under  the  individual  Functions 
in  subsection  3.4.  Examples  of  job  input  are  shown  in 
Appendix  B. 

The  PSL  Function  cards  are  processed  in  the  order  in  which 
they  are  encountered  in  the  run  stream  (with  the  exception 
of  the  subfunctions  under  a  CHANGE,  DOCUMENT,  MDPLAN , 

MDFORMAT ,  or  MDUPDATE  Function).  Thus  a  user  may  prepare  a 
library  and  use  the  library  in  the  same  activity.  The  end  of 
the  stream  of  PSL  F.unction  cards  (and  their  accompanying  data 
cards)  and  execution  of  the  PSL  system  is  indicated  by  the 
following  cards: 


Col 

1 

@  END  PSL 

aXQT  PSL.BCTL 

The  @ADD  and  @  END  are  Exec  8  control  cards  and  must  follow 
the  formats  for  such  cards. 

If  Functions  or  options  are  used  which  require  tape 
definiticns,  the  Exec  8  tape  assign  card  with  the  file  name 
UT  is  inserted  after  the  @ END  card.  Examples  are  given 
under  the  appropriate  Functions. 
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The  following  subjects,  which  have  general  application  over 
several  PSL  Functions,  are  discussed  below: 

a.  High-level  parameters 

b.  Multi-library  search 

c.  Independent  files 

d.  File  Management  Space 

e.  Spawned  jobs 

f.  Stub  generation 

g.  Error  handling 

h.  INCLUDE  statements 

i.  Name  lengths  and  restrictions 

j .  Management  data  facility 

k.  Special-case  card  data 

3.2.1  High-Level  Parameters 

The  following  parameters  are  cumulative  during  execution  of 
the  PSL  system: 


a  . 

PROJECT 

Project 

name 

b. 

LIBRARY 

Library 

name 

c  . 

SECTION 

Section 

name 

d. 

PASSWORD 

Section 

password 

e  . 

PGMR 

Program 

name 

Once  the  value  for  each  of  these  keywords  is  established, 
either  by  a  Function  card  or  by  derault,  it  remains  in  effect. 
All  of  these  parameters  may  be  replaced  by  another  value  by 
using  the  keyword  on  another  Function  card.  A  PARAM  Function 
card  i s  ordinarily  used  to  establish  these  values,  but  the 
keywords  may  appear  on  any  Function  card  for  which  they  are 
valid.  A  section  password  is  required  to  access  a  section  if 
the  password  was  assigned  when  the  section  was  created  and  if 
the  processing  will  modify  the  contents  of  the  section. 

3.2.2  Multi-Library  Search 


The  following  Functions  allow  an  optional  multi-library  search 
during  retrieval  of  input: 

a.  COMPILE 

b.  LINK 

c.  EXECUTE 

d.  MDCOLLECT 

e.  MDPRINT 


A  maximum  of  nine  libraries  may  be  searched. 
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The  order  of  the  search  through  the  libraries  is  determined 
by  the  numerical  digit  in  the  following  two  special  sets  of 
keywords : 


a.  PRO  J  1 ,  PRO  J  2  ,  PRO  J  3 . PRO  J  9 

b.  LIB1 ,  LIB2,  LIB3 . LIB9. 

Corresponding  numeric  digits  are  always  paired,  if  they  are 
declared,  as: 

PR0J1/LIB1, PRO J  2 / LI B  2  ,etc  . 

It  is  not  necessary  to  use  all  intermediate  numerics.  If 
specific  numerics  are  skipped  in  one  set  and  not  skipped  in 
the  other,  the  preceding  value  for  that  set  of  keywords  is 
used  . 


Example : 

PROJl-project-one,  PR0J3=project-three 

LIBi*=library-one,LIB2*=library-two,LIB3  =  library-three 
These  sets  of  keywords  result  in  the  following 
search  sequence  : 

First  -  project-one/library-one 

Second  -  p r o j ec t -one / 1 ibrary- two 

Third  -  pro ject-three/library-three 

The  keyword  PR0J1  is  synonomous  with  PROJECT,  and  the  keyword 
LIB1  is  synonomous  with  LIBRARY,  in  the  five  PSL  Functions 
COMPILE,  LINK,  EXECUTE,  MDCOLLECT  and  MDPRINT . 

3.2.3  Independent  Files* 

The  PSL  system  is  designed  to  store  card-image  data  in  blocks 
in  a  random  file.  (See  the  discussion  of  the  Structure  of  a 
Section  in  Appendix  A.)  This  card-image  data  is  read  by 
special  PSL  access  routines  when  it  is  retrieved  by  modules 
in  the  PSL  system.  However,  if  the  data  must  sometimes  be 
read  by  programs  outside  the  PSL  system,  the  data  may  be  stored 
in  a  separate,  or  independent  file.  Examples  of  such  data  are 
unstructured  code,  which  will  be  ready  by  a  standard  compiler, 
and  test  data,  which  will  be  read  by  a  user's  program. 

When  a  unit  is  added  to  a  section,  the  user  may  specify  the 

unit-type,  if  the  default  type  is  not  appropriate.  (Default 
values  are  discussed  under  the  ADD  Funcf  io"  subsection  3.4.1). 
If  the  user  adds  a  new  unit  (to  the  SOI RCE  section)  for  which 
the  language  is  not  a  structured  language  supported  by  a 

*The  General  Preprocessor  can  be  used  as  an  alternative  method 

for  storing  unstructured  source  code.  See  Appendix  1. 
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precompiler  in  the  PSL  system,  the  system  will  create  an 
independent  sequential  file  for  the  data.  Since  an  unstructured 
unit  is  not  processed  by  a  precompiler  and  INCLUDE  statements 
are  not  resolved,  the  independent  SOURCE  unit  must  be  a  complete 
compilable  set  of  code  and  may  not  be  reduced  to  smaller  units, 
as  may  be  done  with  structured  code. 

3.2.4  File  Management  Space  (FMS)  Parameter 

The  File  Management  Space  Parameter  allows  the  user  to  specify 
the  size  of  files  to  be  created  by  PSL.  The  PSL  keyword  "FMS" 
has  two  values.  The  first  value  is  the  number  of  tracks 
reserved  and  the  second  is  the  maximum  number  of  tracks  allowed. 
For  the  Project  Index  and  Section  files,  with  the  exception  of 
the  PROGRAM  section,  the  number  of  tracks  reserved  must  equal 
the  maximum  number  of  tracks.  The  PROGRAM  Section  and 
Independent  units  can  have  different  values  for  the  reserved 
and  maximum  tracks.  The  standard  defaults  for  the  various 
files  are  gi  van  in  Figure  3-10. 

3.2.5  Spawned  Jobs 

Certain  PSL  Functions,  called  job  spawning  Functions,  require 
the  execution  of  independent  programs  such  as  precompilers, 
compilers  or  user  written  programs  as  part  of  their  processing. 

To  invoke  an  Independent  program,  the  PSL  Function  retrieves 
a  pre-stored  JCL  procedure,  modifies  the  JCL  and  writes  the 
modified  JCL  on  a  temporary  file.  Subsequent  Functions  may 
append  additional  JCL  on  this  file.  Also,  JCL  may  be  added 
directly  to  this  file  by  the  user  with  the  JCL  Function. 

When  the  end  of  the  PSL  input  is  reached  and  all  the  PSL 
Functions  have  been  processed,  the  temporary  JCL  file  is 
extended  (@ADD)  onto  the  user's  run. 

The  job  spawning  Functions  are  COMPILE,  LINK,  EXECUTE,  MDCOLLECT , 
MDPRINT,  and  JCL.  JCL  procedures  provided  with  the  PSL  system 
for  use  with  these  Functions  are  described  in  Appendix  D.  The 
EXECUTE  Function  invokes  the  users  program  using  the  JCL  stored 
by  the  user  in  the  JOB  section  of  his  library.  User  stored  JCL 
is  described  in  section  3.4.9  with  the  EXECUTE  Function. 
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Func  t ion 

File 

File 

Mode 

INITIAL 

Project  Index 

Random 

CREATE 

Section 

Random 

CREATE 

Project  Section 

Project  File 

ADD 

Indep.  unit  only 

Sequential 

File  Size 
in  TRACKS 
(reserved,  max.) 

2,2 

10,10 

10,10 

1,2 


Figure  3-10.  Default  File  Parameters 
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The  user  should  not  use  the  TERMINATE  Function  (to  purge  a 
section)  In  the  same  run  with  a  job  spawning  Function  which 
uses  that  section.  The  spawned  job  will  not  execute  until 
after  the  other  Functions,  such  as  TERMINATE,  have  completed, 
and  required  section  will  no  longer  exist. 

3.2.6  Stub  Generation 

The  PSL  generates  stubs  for  missing  units  under  two 
conditions : 

a.  When  structured  source  code  Is  added  to  a  library, 
a  dummy  SOURCE  unit  (SOURCE  stub)  Is  provided  for 
any  unit  v  lch  is  referenced  in  an  INCLUDE  state¬ 
ment,  but  has  not  yet  been  added  to  the  library. 

See  description  of  the  INCLUDE  statement  under 
subsection  3.2.8.  Accounting  Information  for  the 
source  stub  Is  stored  in  the  SOURCE  section  of  the 
user's  library . 

b.  When  an  object  module  Is  requested  on  an  INCLUDE 
card  In  the  user's  collector  control  cards  and  the 
object  module  Is  not  found  by  the  PSL  system,  a 
dummy  object  module  (OBJECT  stub)  is  provided  to 
the  Collector  by  the  system.  A  message  will  be 
printed  on  the  system  output  file  when  the  object 
stub  Is  executed.  The  object  stub  is  not  In  the 
user's  library. 

3.2.7  Error  Handling 

When  an  error  Is  encountered  on  a  Function  card,  an  error 
message  Is  generated  and  the  remaining  keywords  for  that 
Functions  are  scanned,  but  no  library  processing  Is  done. 
Input  Is  read  and  printed,  but  not  processed,  until  the  next 
Function  card  is  found.  If  an  error  Is  found  on  a  PARAM 
Function,  no  processing  takes  place  until  another  PARAM 
Function  card  is  found. 
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If  an  error  occurs  while  processing  a  Function,  the  PSL  system 
will  attempt  to  undo  whatever  processing  has  taken  place  and 
will  then  terminate  the  Function.  Advisory  and  error  messages 
(see  Appendix  C)  will  be  generated.  Processing  will  resume  at 
the  next  Function  card. 

It  is  recommended  that  a  PARAM  Function  card  be  used  to  estab¬ 
lish  high-level  parameters,  to  assure  that  intermediate  Function 
cards  will  be  skipped  when  one  of  these  parameters  is  in  error. 

3.2.8  INCLUDE  Statements 

An  INCLUDE  statement  is  used  in  source  code  and  with  loader 
control  cards  to  re'er  to  a  unit  which  will  be  retrieved  and 
substituted  in-line  for  the  INCLUDE  statement.  The  format  of 
the  INCLUDE  statement  is: 

numerics  INCLUDE  unit-name 

Leading  numerics  are  ignored.  The  word  "INCLUDE"  must  be 
preceded  by  at  least  one  space  or  must  begin  in  column  one. 

The  unit-name  must  be  preceded  by  at  least  one  space  and  is 
terminated  by  a  space,  a  period,  a  comma,  a  semi-colon,  or  a 
dollar-sign.  Columns  73  through  80  are  Ignored.  An  INCLUDE 
statement  may  not  be  continued. 

The  INCLUDE  statement  may  be  used  in  the  SOURCE,  PDL ,  and  LINK 
sections  as  follows: 

a.  SOURCE  -  When  the  INCLUDE  statement  is  used  as  a  line 
of  code  in  a  SOURCE  unit,  it  refers  to  a  lower-level 
unit  of  SOURCE  code  which  will  be  substituted  in-line 
for  the  INCLUDE  statement.  Such  INCLUDE  statements 
are  resolved  by  a  preprocessor  before  the  code  is 
passed  to  the  compiler.  Therefore,  INCLUDE  statements 
may  only  be  used  in  modules  which  are  written  in 
SCOBOL,  SJOVIAL  or  SPFORT,  or  modules  which  are 
processed  by  the  General  Preprocessor  (see  Appendix  I) . 
Independent  units  may  not  be  INCLUDED  by  other  units 
and  should  not  contain  INCLUDE  statements.  When  a 
non-independent  unit  is  added  to  a  SOURCE  section,  or 
modified,  the  INCLUDE  references  are  checked.  If  an 
included  unit  does  not  exist  in  the  section,  a 
SOURCE-stub  unit  is  created  and  is  tagged  with  the 
name  and  language  of  the  including-unit .  When  the 
including-unit  is  compiled,  the  lower-level  unit  is 
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a  atub,  an  appropriate  statement  la  Inserted  by 
the  preprocessor  to  generate  an  output  message 
when  the  code  Is  executed.  INCLUDE  statements 
may  be  nested  to  a  depth  of  50  levels.  The 
hierarchical  pattern  of  nesting  may  be  Inserted 
by  Invoking  the  Program  Structure  (PS)  report 
under  the  MDPR1NT  Function.  If  an  error  Is 
detected  during  the  INCLUDE  processing,  an 
appropriate  message  is  printed  and  a  "X"  Is  Inserted 
Immediately  before  the  word  "INCLUDE"  in  the  user's 
code . 

b.  PDL  -  The  INCLUDE  statement  is  processed  In  the  PDL 
section  in  the  same  way  as  in  the  SOURCE  section. 

A  Program  Structure  report  may  be  generated  for  a 
unit  In  the  PDL  section. 

c.  OBJECT  -  When  the  INCLUDE  statement  Is  used  with 
collector  control  cards  In  the  LINK  section.  It 
refers  to  a  compiled  unit  (a  module)  in  the  OBJECT 
section  for  which  an  IN  card  will  be  Inserted  Into 
the  input  stream  passed  to  the  Collector.  If  the 
unit  is  not  found  in  the  libraries  selected  on  the 
LINK  (or  EXECUTE)  Function  card,  an  OBJECT-stub 
unit  is  substituted  in  its  place  (with  the  unit-name 
as  the  external-name  of  the  stub).  This  unit  appears 
as  a  "STUB"  in  the  load  map  of  the  user's  program 
and  a  message  will  be  printed  when  the  OBJECT  stub 

1 8  executed. 


3.2.9  Name  Lengths  and  Restrictions 


The  maximum  lengths  allowed  for  the  various  types  of  user- 
assigned  names  are  tabulated  in  Figure  3-11. 


3.2.10  Management  Data  Cycling  and  Archiving  Operations 


Data  cycling  is  the  periodic  resetting  of  those  management 
data  items  for  which  values  have  been  accumulated  over  a 
period  of  time.  Data  cycling  can  be  optionally  defined  to 
permit  the  user  to  specify  the  period  for  which  values  are 
to  be  accumulated  before  being  reset. 
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Maximum 

Length 


Comments 


Project 

Library 


Section 


"SYSTEM",  "PROJECT"  may 
not  be  used. 

Standard  names  only. 


Units 


'ALL"  may  not  be  used. 


SOURCE  section 


MAIN 

CALLED 

INDEP 


Top  unit  may  become 
program  ID. 


INCLUDED 


LINK  section 


Name  becomes  LOAD  entry 
and  absolute  element  name 


Other  sections 


INDEP 


Stored  as  separate  file. 


Other  types 


Figure  3-11.  Name  Lengths  and  Restrictions 
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Archiving  enables  the  user  to  retain  previously  collected 
data  for  e  historical  review  of  project  status. 

3.2.10.1  Cyclic  Data  Operations 

"Cyclic"  management  data  is  first  Implemented  in  the  Unit 
Accounting  Record  for  PSL  sections  in  which  the  MGMT"YES 
option  is  indicated.  Two  cyclic  data  items  are  maintained  in 
that  record:  lines  input  per  cycle  and  number  of  updates  per 
cycle.  A  project  is  given  the  option  of  defining  the  duration 
of  the  unit  level  cycle  thrugh  one  of  the  following  methods: 

a.  Unit  level  cycle  -  If  a  format  unit  for  unit  level 
data  is  established,  the  cycle  duration  for  cyclic 
items  in  the  unit  accounting  record  can  be  specified. 

b.  Module  level  cycle  -  In  lieu  of  establishing  a 
format  unit  for  unit  level  data,  the  cycle  duration 
established  in  the  format  unit  for  module  level  data 
will  be  applied  to  the  unit  accounting  record. 

The  determination  as  to  when  the  specified  cycle  period  has 
elapsed  is  made  when  a  management  data  collection  is  performed. 
If  the  number  of  days  specified  for  the  cycle  period  is  equal 
to  or  exceeds  the  number  of  days  elapsed  since  the  accumulation 
of  cycle  statistics  was  begun,  the  cyclic  data  item  contents 
will  be  reset  to  zero  (i.e.,  recycled)  after  the  collection  of 
that  data.  A  new  data  cycle  is  started  and  cycle  duration  is 
determined  from  that  date  for  all  SOURCE  section  units  linked 
through  the  management  plan;  that  is,  through  the  module  names 
listed  in  the  management  plan  unit. 

Cyclic  data  items,  as  described  in  the  module,  job,  subsystem, 
and  system  level  formats,  are  defined  through  the  MDFORMAT 
Function  (paragraph  3.4.15),  while  the  unit  accounting  record 
items  are  pre-defined  by  the  PSL  system. 

Cyclic  data  items  are  specified  in  a  given  level  format  unit  to 
compute  the  cumulative  changes  in  value  of  other  items  in  that 
same  format.  For  example,  if  "total-llnes-added"  is  defined 
as  an  item  at  the  module  level  (derived  from  a  summation  of  the 
equivalent  item  in  the  Included  unit's  accounting  record),  a 
cyclic  data  item  may  be  defined  to  compute  the  number  of  lines 
added  during  the  period  of  time  defined  by  the  cycle.  The 
defined  " lines-added-per-cyc le"  item  will  reference  the 
"total-llnes-added"  item  with  the  indication  that  a  cyclic 
accumulation  is  required. 
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The  ability  to  define  cyclic  data  Items  extends  to  the  system 
level  format  which  represents  the  top  level  of  data  collection 
and  summarization  for  a  project.  It  is  suggested  that  the 
cycle  duration  for  the  system  level  record  might  be  greater 
than  for  the  subsystem  level  and  that,  in  turn,  might  be 
greater  than  for  the  module  level  record.  For  example,  the 
system  level  data  may  be  cycled  on  a  monthly  basis,  the 
subsystem  on  a  bi-weekly  basis,  and  the  module  on  a  weekly 
basis . 

Archiving  of  collected  data  might  be  performed  for  system 
level  data  only  at  the  end  of  the  system  level  cycle  period. 
Cyclic  data  item  values  in  the  archived  system  level  record 
would  thereby  represent  the  change  in  value  of  referenced 
items  as  has  occurred  during  the  cycle  just  concluded. 

3.2.10.2  Archiving  Data 

Automatic  archiving  is  generally  associated  with  the  conclusion 
of  the  system  level  cycle  period.  However,  an  option  to 
archive  other  than  system  level  data  is  provided  to  permit  any 
or  all  levels  to  be  archived.  The  determination  to  automatically 
archive  is  made  when  the  data  is  collected,  based  upon  the 
current  date,  the  start-of -cycle  date,  and  the  cycle  duration. 
Actual  archiving  is  not  performed,  however,  until  the  next  data 
collection  remains  the  "current"  data  collection  until  such 
time  as  it  is  archived  and/or  replaced. 

Although  automatic  cycling  and  archiving  may  be  flexibly  defined 
and  used  to  satisfy  most  user  requirements,  a  manual  cycling  and 
archiving  capability  is  provided  to  ensure  that  special  user 
requirements  are  accommodated  (paragraph  3.4.14,  MDCOLLECT) . 

The  options  to  manually  suppress  or  enable  cycling  and/or 
archiving  are  available  for  each  data  collection  performed. 

This  capability  may  be  used  in  combination  with  the  automatic 
cycling  and  archiving.  It  is  also  possible  to  suppress  the 
automatic  cycling  option  so  that  only  manual  cycling  and/or 
archiving  is  performed. 

Each  archived  unit  is  uniquely  identified  at  the  time  of 
archiving  by  affixing  a  suffix  to  its  basic  name.  This  suffix 
consists  of  a  three  digit  serial  number  and  a  six  character 
date.  The  assign ea  serial  number  (starting  with  001)  is 
increased  by  one  for  each  subsequent  collection  archived.  The 
six  character  date,  given  in  MMDDYY  format,  signifies  the  day 
on  which  the  data  collection  was  performed. 
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The  PSL  INDEX  Function  can  be  used  periodically  to  obtain  a 
list  of  the  MGMT  section  units.  A  scan  of  this  listing  will 
give  a  very  quick,  indication  of  the  specific  dates  on  which 
archived  data  was  collected  and,  in  reviewing  the  serial 
number  designations,  determine  whether  any  archived  collections 
are  missing.  The  ordering  of  archived  collection  units  by 
serial  number  allows  for  a  rapid  determination  of  the  elapsed 
days  between  successive  archives. 

While  it  is  of  considerable  convenience  to  retain  the  more 
recently  archived  collections  in  the  Project  MGMT  section, 
each  such  collection  tak.es  up  section  storage  space.  Two 
options  are  open  to  the  user  when  the  remaining  free  space 
drops  below  a  determined  threshold: 

a.  TERMINATE,  CREATE,  and  RESTORE  -  the  section  can  be 
terminated  using  the  TERMINATE  Function  with  the 
BACKUP  option,  recreating  the  MGMT  section  with  a 
larger  space  allocation  using  the  CREATE  Function, 
and  restoring  the  backup  file  using  the  RESTORE 
Function . 

b.  BACKUP  and  PURGE  —  the  section  can  be  backed- up 
using  the  BACKUP  Function  and  archived  collections 
can  be  selectively  deleted  using  the  PURGE  Function. 

T  he  latter  method  could  be  used  to  remove  the  older  archived 
collections  from  the  MGMT  section.  The  backup  tape  produced 
in  that  operation  should  be  retained  and  labeled  to  provide 
for  the  restoration  of  purged  archive  units  when  and  if 
required . 

The  procedures  to  be  followed  for  administering  and  controlling 
backup  and  archived  material  are  a  prerogative  of  the  user  or 
the  site.  Currently,  the  PSL  facility  is  designed  to  provide 
a  practical  means  for  storing  and  selectively  retrieving 
archived  data  prerequisite  to  the  production  of  management 
data  history  reports. 


3.2.11  Special-Case  Card  Data 


The  user  may  wish  to  enter  PSL  Function  or  Subfunction  cards 
as  data.  A  special  handling  facility  Is  provided  to  enable 
cards  with  "**#"  in  the  first  three  columns  to  be  maintained 
in  a  card-image  data  unit.  The  addition,  replacement,  and 
insertion  of  this  special-case  card  data  Is  accomplished  by 
enclosing  the  data  within  a  PSL  DATA/PSL  ENDATA  card  pair. 

The  format  of  the  PSL  DATA  card  and  the  PSL  ENDATA  card 
follows : 

**  DATA  initial-character 
(data  cards) 

**  ENDATA  closing-character 

The  initial-character  must  match  the  closing-character  to  mark 
the  end  of  the  data  stream. 

The  following  example  shows  how  a  user  may  maintain  units 
containing  special-case  card  data: 

**  PARAM  PROJ-UMC1234 , LIBRARY-NEWCODE , SECTION-TEST 
**  ADD  UNIT-NEWTEST.UTYPE-MAIN 
**  DATA  A 

**  PARAM  PROJ-UMC1234 , LIBRARY-NEWCODE , SECTION-SOURCE 
**  CHANGE  UNIT-TIPTOP 

**  D  L- (1,10) 

**  M  L-14.C-12 ,T-NEW 

**  COMPILE  UNIT-TIPTOP , PROCEDURE-COBOL 
**  ENDATA  A 

**  CHANGE  UNIT-NEWTEST 

**  M  L-l 

**  DATA  A 

**  PARAM  PR0J-UMC456 , LIBRARY- JOHN .SECTION-SOURCE 
**  ENDATA  A 
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3.3  Conventions  and  Glossary 


3.3.1  Format  Conventiona 


The  following  conventiona  will  be  employed  In  formats  and 
examples : 


a.  PSL  Function  card  parameters  are  shown  In  upper 
case  If  the  parameters  are  to  be  entered  exactly 
as  shown. 


b.  PSL  Function  card  parameters  are  shown  in  lower 
case  If  the  parameters  are  to  be  replaced  by  the 
user  with  appropriate  Information. 

c.  Square  brackets  []  indicate  that  the  enclosed 
Item  is  optional  and  may  be  omitted. 

d.  Braces  j  }  Indicate  that  one  of  the  enclosed 
values  should  be  used. 


e.  A  literal  string  is  a  string  of  characters  (in 

the  Sperry  Univac  1100  series  character  set)  bounded 
by  quotation  marks. 

f.  When  more  than  one  value  choice  Is  indicated  for 
a  keyword-value-entry  and  one  of  the  values  is 
underlined,  the  underlined  value  will  be  provided 
as  the  default  value  if  the  keyword  is  omitted. 

g.  The  ellipsis  ...  indicates  that  the  preceding  item 
may  be  repeated. 


3.3.2  Glossar; 


The  following  terms  are  used  in  this  document  with  the 
associated  specific  meanings: 


a.  A  "Function"  is  one  of  28  PSL  operations  which  is 
invoked  with  a  PSL  card  as  defined  in  subsection 
3.4.  The  valid  PSL  Functions  are  shown  in  Figure 
3-12  . 
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Func  t ions 

Keywords 

ADD 

AUTHOR 

PSL 

BACKUP 

AFTER 

OP 

CHANGE 

ALL 

OPGMR 

COMPILE 

ARCHIVE 

OPTION 

CREATE 

BACKUP 

OUTPOOL 

CSCAN 

DOCUMENT 

CALL 

PAGE 

EXECUTE 

COLUMN 

PASSWORD 

INDEX 

COMPRESS 

PGMR 

INITIAL 

CYCLE 

PLINES 

JCL 

ELEMENT 

PROCEDURE 

LINK 

FILE1-9 

PRO  J1 

MDCOLLECT 

FMS 

• 

MDFORMAT 

FROM 

. 

MDPLAN 

HISTORY 

• 

MDPRINT 

HPRINT 

PRO  J  9 

MDUPDATE 

HSPACE 

PROJECT 

MDXCHECK 

INDENT 

RECYCLE 

MOVE 

INPOOL 

REPLACE 

PARAM 

JOB 

REPORT 

PERFORM 

KEY 

SECTION 

PRECOMPILE 

LADJUST 

SPCHECK 

PURGE 

LANGUAGE 

SPLENGTH 

REPLACE 

LEVEL 

STANDARD 

RESTORE 

LIB1 

START 

SOURCE 

. 

STRING 

TERMINATE 

. 

SYSTEM 

. 

SUBSYSTEM 

LIB9 

TO 

Subf  unc  t ions 

LIBRARY 

LINE  (S) 

UNIT 

COPY 

LINK 

UPGMR 

DELETE 

LOAD 

USPACE 

EJECT 

UTYPE 

HEADER 

LSPACE 

INSERT 

MEDIA 

MODIFY 

MGMTDATA 

SHIFT 

MOD 

SPACE 

MODULE 

TEXT 

NBRLINES 

NEST 

OBJECT 

OLDLIB 

OLDPROJ 

OLDSEC 

OLDUNIT 

Figure  3-12.  Functions,  Sub f unc t  ions  ,  and  Keywords 
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A  "  Sub  f  unc  t  ion "  is  one  of  nine  PSL  directives 
which  are  used  only  after  a  CHANGE  or  DOCUMENT 
Function  card.  They  are  COPY,  DELETE,  EJECT, 

HEADER,  INSERT,  MODIFY,  SHIFT,  and  TEXT. 

A  "keyword"  is  a  word-symbol  used  to  identify 
a  parameter  on  a  PSL  Function  card.  The  first 
four  letters  of  keywords  (.except  PRO  J  2  .  .  .  PRO  J  9  , 

FILE1 . . . F ILE9 )  must  be  spelled  exactly  as  given 
in  Figure  3-12  or  the  PSL  system  will  not 
recognize  the  keyword. 

A  "module"  is  a  compilable  set  of  code.  It  may 
be  retrieved  from  one  or  more  units  in  the  Source 
section.  Compilation  will  result  in  one  unit  in 
the  OBJECT  section.  A  module  is  not  necessarily 
executable  independently. 

A  "program"  is  an  independently  executable  set 
of  code.  The  code  may  consist  of  one,  or  more 
than  one,  relocatable  element  from  a  PROJECT  section. 
Linking  a  program  will  result  in  one  absolute 
element  in  the  PROJECT  section,  which  may  be 
executed,  and  an  appropriate  record  in  the  LOAD 
section- 

The  special  characters  "/",  and  are 

required  if  they  appear  in  the  format  of  a  Function 
card  . 
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3 . 4  Input  Format  of  Function  Cards 


The  general  format  of  a  PSL  Function  card  is: 

col 

1 

**  function  key word* va lue -e n t ry , ke ywor d=va lue -en t r y  ... 

where  value-entry  may  be: 

a .  va lue 

b .  (value , va lue ) 

The  presence  of  "**  "  in  columns  1  through  3  indicates  that 
card  is  a  PSL  Function  card  or  a  PSL  continuation  card.  The 
name  of  the  Function  may  begin  in  any  column  after  column 
three,  but  it  must  terminate  before  column  73.  Columns  73 
through  80  ari  ignored  by  the  PSL  system.  The  keyword-value- 
entries  follow  the  Function  name,  and  the  first  keyword  must 
be  preceded  by  one  or  more  blanks.  After  the  beginning  of 
the  first  keyword,  a  blank  ends  the  scan  of  a  PSL  Function 
card.  The  remainder  of  the  card  is  ignored.  The  keyword- 
value  -en  t  r  ies  may  be  interrupted  after  any  comma  (unless  the 
comma  is  inside  quotes)  and  continued  on  a  PSL  continuation 
card.  The  data  on  a  continuation  card  may  begin  in  any 
column  after  column  three  and  may  be  continued  through 
column  72.  A  subsequent  blank  will  terminate  the  scan.  If 
keyword-value-entries  are  present,  at  least  one  keyword  must 
appear  on  the  same  card  as  the  Function.  The  valid  PSL 
keywords  are  listed  in  Figure  3-12.  All  PSL  keywords,  except 
PROJ 2 . . . PROJ 9  and  FILE1 . . . FILE9 ,  may  be  abbreviated  to  four 
characters.  In  addition,  the  Subfunctions  under  the  CHANGE 
and  MDPLAN  Functions,  and  the  associated  Subfunction  keywords, 
may  be  abbreviated  to  one  character. 

Examp 1 e : 

**  PARM  PROJ-FHACD147 ,LIBR=PR0VEN, SECT-SOURCE 
**  CHANGE  UNIT-TIPTOP 
**  M  L«(10,12) 

(new  source  data  cards) 

**  D  L-14 

**  ADD  SECT-JOB , UNIT-TIPTOP 
(JCL  for  user's  execution) 
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If  a  keyword  value  contains  one  of  the  special  characters  "/"» 
")",  quote,  or  space,  the  value  must  be  enclosed  In 

quotation  marks.  Within  quotation  marks,  the  occurrence  of 
two  quotation  marks  in  sequence  are  interpreted  as  a  single 
quotation  mark  and  part  of  the  value. 

The  detailed  specifications  for  the  keywords  and  value  for 
each  PSL  Function,  with  explanatory  information,  are  given  on 
the  following  pages.  Multiple  keyword/value  pairs  may  be 
grouped  on  a  single  PSL  Function  card. 

The  user  may  insert  source  data  cards  by  means  of  an  @ADD,D 
card  . 
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3.4.1  ADD 


The  ADD  Function  is  used  for  the  original  introduction  of 
data  into  a  unit.  The  accounting  information  for  the  unit 
is  initialized  by  the  ADD  Function.  The  actual  data  cards 
for  the  unit  follow  the  ADD  Function  card  in  the  run  stream 


**  ADD 

PROJECT-project-name , 

★  * 

LIBRARY- library-name , 

** 

SECTION -section-name , 

*  * 

PAS SWORD-sect ion-pas  sword 

** 

UNIT-unit-name , 

*  * 

LANGUAGE=language-name , 

[  *  * 

KEY=unit-key , ] 

[  *  * 

UTYPE-unit-type,] 

[  ★  * 

FMS=fms-entry,] 

[  ** 

PGMR-programmer-name] 

The  values  for  the  ADD  parameters  are: 

project-name  -  name  of  project. 

library-name  -  name  of  library. 

section-name  -  name  of  section;  must  be 

SOURCE,  PDL ,  JOB,  LINK,  TEST, 
or  TEXT. 

section-password  -  password  which  was  assigned 

when  the  section  was  created; 
not  required  if  a  password 
was  not  assigned. 

unit-name  -  name  of  unit  to  be  added; 

maximum  length  of  30  characters; 
maximum  length  of  12  characters 
if  unit-type  is  INDEPENDENT  or 
if  unit  is  being  added  to  LINK 
section;  maximum  length  of JZ 
characters  if  unit  is  a  top  unit 
(unit-type  is  MAIN,  CALLED, 
INDEPENDENT)  in  SOURCE  section; 
ALL  is  a  reserved  word  and 
cannot  be  used  for  a  unit-name. 


I 

I 

language- name 

I 

1 

l 

1 

j  unit-key 

uni t-t y pe 

i 

i 

I 

i 

J  fms-entry 


pro  g rammer -name 


the  name  of  the  programming 
language  for  the  unit  ;  required 
only  in  SOURCE  section  for  a  top 
unit  (MAIN,  CALLED,  INDEPENDENT) 
and  for  any  included  unit  for 
which  a  stub  does  not  already 
exist;  language-name  is  not 
checked  for  validity,  but  COMPILE 
Function  is  dependent  on  language- 
name;  maximum  of  eight  characters. 
Units  with  language  SPFORT, 

SJOVIAL  or  SCOBOL  will  be 
automatically  indented  when 
printed  . 

the  key  that  will  be  required 
in  order  to  modify  or  purge  the 
unit;  maximum  of  twelve  characters; 
keys  are  not  checked  for  read-only 
Func  t ions  . 

one  of  the  word-symbols  (MAIN, 
CALLED,  INCLUDED,  INDEPENDENT) 
which  describes  the  structural 
position  of  the  unit;  may  be 
entered  in  four-character 
abbreviated  form  (MAIN,  CALL, 

INCL,  INDE) ;  usually  assigned 
from  default  values  (see  below); 
INCLUDED  and  CALLED  are  valid 
for  SOURCE  and  PDL  sections 
only;  MAIN  and  CALLED  units 
are  processed  the  same,  but 
the  distinction  is  used  in 
Management  Data  reports. 

used  to  enter  FMS  parameters 
for  file;  if  INDEPENDENT  unit 
is  being  added;  default  size 
for  INDEPENDENT  file  is  1 
reserved  track,  2  maximum  tracks. 

name  to  be  placed  in  accounting 
record;  maximum  of  twelve 
characters;  default  is  project 
identification  for  job. 
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A  unit-type  of  INCLUDED  is  not  normally  declared  by  the  user • 

In  top-down  development,  INCLUDEd  units  are  automatically 
generated  in  the  library  as  stubs  with  a  unit-type  of  INCLUDED. 
Code  may  be  added  to  the  stub  unit  with  the  ADD  Function  or  with 
the  REPLACE  Function,  and  there  is  no  need  to  declare  the  unit- 
type  or  the  language.  However,  if  a  unit  is  to  be  an  INCLUDEd 
unit  and  it  is  added  to  a  library  before  a  higher-level  unit 
has  caused  a  stub  to  be  generated  in  that  library,  both  the 
unit-type  (INCLUDED)  and  the  language  must  be  explicity  declared, 

If  a  user  attempts  to  ADD  code  to  a  unit  which  exists  in  that 
library  and  which  is  not  a  stub,  the  ADD  Function  will  be 
rejected.  When  a  unit  is  ADDed  to  a  section,  and  no  stub 
exists,  and  the  unit-type  is  not  provided  as  a  parameter,  the 
following  default  values  are  used: 


Sec  tion 


Unit-Type 


SOURCE 

Structured  language 

(SCOBOL,  SPFORT ,  SJOVIAL) 
Unstructured  language 

(ASM,  COBOL,  FORTRAN, 
JOVIAL) 

PDL 

JOB 

LINK 

TEST 

TEXT 


MAIN 


INDEPENDENT 


MAIN 

MAIN 

MAIN 

MAIN 

MAIN 


The  following  example  builds  the  top  unit  of  a  module  and  adds 
code  to  one  of  the  generated  stubs: 

**  PARAM  PROJ=FHACD129 , LIBR=NEWCODE , SECT 10N= SOURCE , 

**  PGMR-BERT 

**  ADD  UNIT=TIPTOP , LANG-SCOBOL 

(source  cards  for  TIPTOP  main  unit) 

**  ADD  UNIT-TIPTOP-DATA-DIVISION 

(source  cards  for  TIPTOP-DATA-DIVISION  ii eluded  unit) 

The  following  example  adds  an  entire  unstructured  module: 

**  ADD  PR0J-FHACD1A7 , LIBR-UNSTRUC , SECTION-SOURCE, 

**  UN IT-FTPROG , LANG« FORTRAN ,FMS-( 10 ,25) 

(source  cards  for  FTPROG  complete  module) 


Also  see  Appendix  I. 
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3.4.2  AUTHOR 


The  AUTHOR  Function  la  used  for  the  printing  of  a  list  of  unit 
names  (OPTION-INDEX),  or  listings  of  the  actual  units  (OPTION- 
SOURCE),  which  were  originally  generated  by  (PGMR-SMITH)  and/or 
updated  by  (UPGMR-SMITH)  a  specific  programmer.  The  OPTION- 
SOURCE  can  only  be  used  for  units  which  are  in  card-image 
format;  that  is,  units  in  the  SOURCE,  PDL,  LINK,  JOB,  MGMT , 
TEXT,  and  TEST  sections. 


**  AUTHOR  PRO JECT-pro j ec t-name  , 

**  LIBRARY-librar y-name  , 

**  SECTION-section-name , 

**  (OPTION-  SOURCE  l 

^  INDEX  f  ’ 

**  J OPGMR-or igina ting-programmer  ,1  only  one  required 

**  jUPGMR-update-programmer  J 

The  values  for  the  AUTHOR  parameter  are: 


project-name 
library-name 
sect  ion-name 


op  t ion-source 


name  of  project . 
name  of  library. 

name  of  section;  if  OPTION-SOURCE, 
must  be  SOURCE,  PDL,  LINK,  JOB, 
MGMT,  TEST,  or  TEXT. 

required  if  source  listing  of 
units  are  desired;  the  default 
value  Is  INDEX,  which  lists  only 
t;:e  unit  name  and  associated 
information;  the  INDEX  option 
applied  whenever  the  OPTION  key¬ 
word  is  omitted. 


or iginating- 

programmer  -  the  name  of  the  programmer  who 

originally  added  the  unit  to  a 
section . 


update-programmer  -  the  name  of  the  programmer  who 

last  updated  the  unit. 


One  of  the 
Func  t ion . 
programmer 
used  alone 
originally 


keywords,  OPGMR  or  UPGMR,  is  required  for  the  AUTHOR 
Both  may  be  used  only  if  the  values  of  originating- 
and  update-programmer  are  the  same.  If  OPGMR  is 
the  listing  will  contain  all  units  which  were 
added  to  the  section  by  a  specific  programmer.  If 
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the  update-programmer  Is  different  from  the  originating- 
programmer,  the  name  of  the  update-programmer  will  also  be 
printed  on  the  Index  listing.  If  UPGMR  la  used  alone,  the 
listing  will  contain  all  units  in  the  section  which  were 
last  updated  by  a  specific  programmer.  If  the  originating- 
programmer  name  is  different  from  the  update-programmer 
name,  the  or iginating-programmer  name  is  also  printed  on  the 
index  listing. 

The  following  example: 

a.  prints  a  source  listing  of  all  units  originated  by 
a  programmer  named  STARTER, 

b.  prints  an  index  listing  of  all  units  which  were 
last  updated  by  a  programmer  named  FIXER,  and 

c.  prints  an  index  listing  of  all  units  which  were 
originated  and/or  last  updated  by  a  programmer 
named  SUPER. 


** 

PARAM 

PROJ-FHACD129 , LIBR-NEWCODE , SECT- SOURCE 

** 

AUTHOR 

OPTION-SOURCE ,PGMR“ STARTER 

** 

AUTHOR 

UPGMR-FIXER 

** 

AUTHOR 

PGMR" SUPER , UPGMR* SUPER 

3.4.3  BACKUP 


The  BACKUP  Function  la  uaed  to  save  sections  of  a  library  on 
tape.  The  BACKUP  may  be  invoked  for  a  complete  project,  a 
library,  or  a  section. 

**  BACKUP  PROJECT*pro ject-name , 

**  LIBRARY*  flibr  ar  y-namel 

IALL  J  ’ 

**  SECTION*  fsection-namel 

[all  J 

plus  a  tape  card  with  a  file  name  of  UT ,  as  follows: 

Col 

1 

<3ASG,C  UT ,  T 

This  la  an  Exec  8  control  card  and  follows  the  appropriate 
format.  The  tape  card  must  be  placed  after  the  @END  PSL  card 
at  the  end  of  the  PSL  Function  cards. 

The  values  for  the  BACKUP  parameters  are: 

project-name  -  the  name  of  the  project;  must 

be  the  same  as  the  project 
identification  on  the  @RUN 
control  card  for  the  job. 

library-name  -  the  name  of  the  library  in 

which  the  section  is  found;  ALL 
indicates  that  all  libraries  in 
the  project  are  to  be  saved. 

section-name  -  the  name  of  the  section  to  be 

saved;  ALL  indicates  that  all 
sections  in  the  library  are  to 
be  saved;  the  section-name  is 
not  required  and  is  ignored  if 
LIBRARY-ALL. 
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The  following  example  will  invoke  the  PSL  system  and  produce 
a  BACKUP  tape: 


Col 

1 

@USE 

@ADD 

**  BACKUP 
@END 
(3ASG.CL 
@XQT 


PSL. , DMA* PSL . 

PSL. RUN 

PROJ=FHACD 129 , LIBR=NEWCODE , SECT=ALL 
PSL 

UT.U9V, Z01620 
PSL. BCTL 


Between  the  @ADD  card  and  the  @END  card,  the  user  may  place 
an  entire  series  of  PSL  Functions,  but  the  user  should  be 
aware  of  the  sequence  in  which  the  output  tape  will  be  used. 
The  tape,  if  present,  is  opened  once  at  the  beginning  oi  the 
job  and  closed  at  the  end.  When  a  Function  is  invoked  which 
uses  this  tape,  the  output  from  that  Function  is  written  on 
the  tape  without  rewinding  the  tape.  Thus  a  user  may  select 
multiple  BACKUP  Functions  and  the  output  will  be  arranged 
sequentially.  A  TERMINATE  Function,  with  BACKUP=YES ,  may 
also  be  inserted  into  this  pattern,  if  desired  by  the  user. 
However,  the  user  must  be  careful  not  to  use  the  SOURCE 
Function,  with  MEDIA=TAPE,  in  the  same  job  as  a  BACKUP  or  a 
TERMINATE-with-BACKUP ,  since  the  resulting  output  would  also 
be  written  sequentially  to  the  same  tape. 

The  BACKUP  Function  tries  to  obtain  FMS  parameter  information 
for  each  independent  unit  file  in  the  section  being  backed-up. 
If  available,  the  FMS  parameters  are  written  on  the  backup 
tape  with  the  file  control  for  use  in  recreating  the  file 
when  the  sections  is  subsequently  restored.  If,  however,  the 
Independent  file  was  created  by  a  user  other  than  the  owner 
of  the  project  (pro j ec t-name*pro j ec t  identification),  the 
BACKUP  Function  cannot  obtain  the  FMS  parameters,  and  only  the 
file  content  is  written  on  the  backup  tape.  In  this  case,  the 
user  can  provide  new  FMS  parameters  for  the  RESTORE  Function 
or  the  RESTORE  will  use  the  PSL  default  values  listed  in 
Figure  3-10. 
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3.4.4  CHANGE 

The  CHANGE  Function  is  used  to  modify  the  contents  of  a  unit. 
Modification  details  ace  provided  on  Subfunction  cards  (COPY, 
DELETE,  INSERT,  MODIFY,  and  SHIFT)  which  follow  the  CHANGE 
card.  New  source  statements  follow  the  INSERT  and  MODIFY 
Subfunction  cards. 


**  CHANGE 

PROJECT-project-name, 

** 

LIBRARY-library-name , 

** 

SECTION-sec tion-name , 

** 

PAS S WORD- se c  t ion -pas sword , 

** 

UNIT-unit-name , 

** 

KEY-unit-key , 

[** 

FMS-f ms-entry , ) 

[** 

LANGUAGE*=new-language-name ,  ] 

[  ** 

MOD-modif icat ion-level , ] 

[** 

PGMR-prog rammer -name ] 

The  values  for  the  CHANGE  parameters  are: 


project-name 

— 

name  of  project. 

library-name 

- 

name  of  library. 

section-name 

- 

name  of  section;  must  be  SOURCE 
PDL ,  JOB,  LINK,  TEST  or  TEXT. 

section-password 

password  which  was  assigned 
when  the  section  was  created; 
not  required  if  a  password  was 
not  assigned. 

unit-name 

- 

name  of  unit  to  be  changed. 

unit-key 

koy  which  was  assigned  to  unit 
when  it  was  added  to  section; 
not  required  if  a  key  was  not 
assigned  . 

fms-entry 

— 

used  to  change  FMS  parameters 
for  file  if  unit  was  an 
INDEPENDENT  unit. 
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new- language-name 


new  name  to  replace  current 
value  of  language-name  in  unit. 


modification-level  -  number  to  be  checked  against 

modification  level  In  unit 
accounting  record;  a  listing  of 
the  unit  is  provided,  but  no 
update  takes  place  if  values  do 
not  match;  maximum  value  of  999. 


programmer-name  -  name  to  be  placed  in  accounting 

record;  maximum  of  12  characters; 
default  is  userid  for  Job. 


The  Subfunctions  which  are  used  to  CHANGE  the  unit  are: 


**  MODIFY  LINES" 

(new  data  cards) 


(line-nbr 

(f irst-line-nbr .last- line-nbr) >  , 

ALL 


or 


**  MODIFY  LINES 


** 

** 


(line-nbr 

(f irst-line-nbr , last-line-nbr 
ALL 

FROM-exi s ting -character-string , 

TO-new- character-string 


>1 


or 


**  MODIFY  LINES-  jline-nbr 

j(f irst-line-nbr .last-line-nbr) 

[all 

COLUMN-star t-column-nbr , 

TO-new-charac  ter-s tr ing 


** 

** 


The  values  for  the  MODIFY  Subfunction  are: 


exlstlng-character-8tring  -  character  string  to  be 

modified;  character  string 
must  be  enclosed  in  quotes 
if  special  characters*  are 
embedded;  maximum  of  40 
character  s 


♦Special  character  (commas,  quotes,  equal-sign,  blanks, 
parenthesis  and  alaahes) 
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new-character-string 


s  tar  t-column-nbr 


**  DELETE  LINES1 


**  SHIFT  LINE* 


replaced  existing  character  string 
on  source  card;  character  string 
must  be  enclosed  in  quotes  if 
special  characters4  are  embedded; 
maximum  of  40  characters.  If 
length  of  a  new  string  exceeds  the 
length  of  the  old  string,  characters 
to  the  right  of  the  old  string  will 
be  shifted  right  with  truncation 
after  column  80. 

-  start  position  on  source  card  where 
first-character  of  new  string  will 
be  placed;  maximum  column  number  is 
80.  Characters  existing  on  the  line 
will  be  replaced. 


line-nbr 

(first-1 ine-nbr , last-1 ine-nbr) 
ALL 

w 

line-nbr 

(f irst-line-nbr , las t-line-nbr  ) 
ALL 


**  COLUMN-shif t-indicator 

The  value  for  the  SHIFT  Subfunction  is: 


shif  t-indicator 


shift-indicator  consists  of  a 
character  code  (direction  value  "R" 
for  right  and  "L"  for  left) 
followed  by  shift-nbr  which  is  the 
number  of  positions  to  be  shifted; 
maximum  value  is  80. 


**  INSERT  AFTER- 


(new  data  cards) 


jline-nbrl 
[ALL  j 


**  COPY  AFTER-  fline-nbr^ 

■(ALL  J 

[**  OLDUNIT-old-unit-name , ] 

**  FROM-  (f rom-line-nbr s 

[(first  f rom-line-nbr .last  f rom-line-nbi 
[all 

[**  OLDPRO J-old-pro j ect-name , ] 

l**  OLDLIB-old-library-name ,  ] 

(**  OLD  SEC T-o Id -s ec t ion-name  ] 

♦Special  character  (commas,  quotes,  equal-sign,  blanks, 
parenthesis  and  slashes) 


L 


i*.  l  Vl  V 


The  values  for  the  COPY  Subfunction  are: 


old-unit-name  -  name  of  unit  from  which  source 

statements  are  taken. 

old-project-name  -  name  of  project  where  old  unit 

is  located;  defaults  to  current 
project. 

old-library-name  -  name  of  library  where  old  unit 

is  located;  defaults  to  current 
library . 

old-section-name  -  name  of  section  which  contains 

old  unit;  must  be  SOURCE,  PDL, 
JOB,  LINE,  MGMT ,  TEST,  or  TEXT; 
defaults  to  current  section. 

f rom-line-nbr a  -  line  number  or  range  of  lines 

of  old  unit  to  be  copied. 

The  Subfunctions  need  not  be  in  any  particular  order.  They 
will  be  sorted  on  beginning-line-number  before  they  are 
processed  by  the  CHANGE  Function.  Input  order  is  preserved 
for  equal  beginning-line-number s .  All  Subfunctions  and  their 
associated  keywords  may  be  abbreviated  to  four  characters  or 
to  one  character. 

A  value  of  zero  is  valid  for  line-nbr  or  f lrst-line-nbr .  If 
the  value  of  last-line-nbr  exceeds  the  highest  line  number  in 
the  unit,  an  error  message  will  be  generated,  but  the  CHANGE 
will  process  the  unit  up  through  the  last  actual  line.  The 
line  numbers  used  on  the  Subfunction  cards  should  be  those 
from  the  last  listing  of  the  unit.  New  line  numbers  will  not 
be  established  for  lines  in  the  unit  until  the  CHANGE  Function 
has  completed  processing. 

The  user  of  INSERT  AFTER«ALL  will  cause  code  to  be  appended 
after  the  last  line  of  the  unit. 

A  single  line  may  not  be  referenced,  during  one  CHANGE 
Function,  more  than  six  times,  either  directly  or  by  Inclusion 
in  a  range.  Excess  references  will  not  be  processed. 

The  CHANGE  Function  updates  a  unit  by  processing  a  line  at  a 
time  and  creating  a  new  copy  of  the  unit.  If  the  unit  is 
INDEPENDENT,  a  temporary  file  is  used.  If  the  unit  is  not 
INDEPENDENT,  space  must  be  available  in  the  section  file  for  a 
temporary  copy  of  the  unit  blocks  or  the  CHANGE  will  not  be 
able  to  complete  processing. 
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After  the  CHANGE  processing  has  terminated,  a  listing  of  the 
unit  is  automatically  generated  showing  the  actual  contents 
of  the  unit  in  the  library. 

The  following  examples  show  how  a  user  may  change  the  contents 
of  a  unit: 

**  PARAM  PR0J-UMC1234 .LIBR-NEWCODE , SECTION-SOURCE 
**  CHANGE  UNIT-TIPTOP , KEY-MYSTERY 
**  C  A-l , OLDU-ADUM ,OLDLIB-PROVEN , FROM- 1 
**  M  L-  (  5 , 9 ) 

(source  cards  to  replace  lines  5-9; 

need  not  be  the  same  number  of  cards) 

**  D  L- ( 10 , 15  ) 

**  I  A-2  3 

(source  cards  to  go  between  line  23  and  line  24) 

**  S  L-24 , COLUMN- RIO 

**  M  L-26 ,T0="M0VE  TO " , FR0M-M0VET0 

The  same  change  would  be  effected  by: 

**  PARAM  PROJ-UMC1234 , L IBR-NEWCODE , SECTION-SOURCE 
**  CHANGE  UNIT-TIPTOP , KEY-MYSTERY 
**  I  A-l 

(source  card  inserted  after  line  1) 

**  I  A-2  3 

(source  cards  to  go  between  line  23  and  line  24) 

**  D  L-  (5,15) 

**  I  A-4  “ 

(source  cards  to  replace  line  5-9) 

**  S  L-24 , C0LUMN-R5 

**  M  L-26 , T0-"M0VE  ".FR0M-M0VE 

**  S  L-24 , C0LUMN-R5 

For  the  CHANGE  of  an  INDEPENDENT  unit,  if  the  space  assigned 
to  the  independent  unit  file  is  insufficient  to  contain  all 
of  the  change  unit,  the  PSL  program  will  abort.  In  this  case, 
the  user  may  use  the  RESTORE  Function  to  restore  the  unit  from 
a  previous  BACKUP  tape  to  its  status  before  the  CHANGE  and 
rerun  the  CHANGE  with  the  FMS  keyword  to  increase  the  size  of 
the  independent  file.  Alternately,  the  SOURCE  Function  may 
be  used  to  obtain  a  listing  of  the  current  contents  of  the 
change  unit.  Then,  a  CHANGE  may  be  used  to  re-enter  any 
source  lines  which  were  truncated  with  the  FMS  keyword  to 
increase  the  size  of  the  independent  file. 
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3 . A . 5  COMPILE* 


The  COMPILE  Function  retrieves  units  from  the  SOURCE  section, 
invokes  the  appropriate  precompiler  if  the  source  code  is 
structured,  compiles  the  resulting  stream  of  code,  records  the 
unit  in  the  OBJECT  section,  and  stores  the  compiled  product  as 
a  relocatable  element  in  the  PROGRAM  section.  The  unit  name 
is  the  name  of  the  top-most  source  unit  of  the  module  which  is 
to  be  compiled.  This  name  will  be  used  for  the  name  of  the 
compiled  OBJECT  unit.  The  processing  which  is  invoked  b^  uhe 
COMPILE  Function  depends  upon  the  language  of  the  unit.  Under 
the  present  PSL  system,  procedures  exist  to  process  languages 
ASM,  ASMG  •'Compacted  ASM),  COBOL,  COBOLG  (Compacted  COBOL), 

SCOBOL  (Structured  COBOL),  FORTRAN,  FORTRANG  (Compacted  FORTRAN), 
SPFORT  (Structured  FORTRAN),  JOVIAL,  JOVIALG  (Compacted  JOVIAL), 
and  SJOVIAL  (Structured  JOVIAL).  Procedure  to  compile 
additional  languages  may  be  added  to  the  system.  Procedures  are 
automatically  invoked  by  the  language-name,  or  may  be  specifically 
Invoked  with  the  PROCEDURE  keyword. 

**  COMPILE  PRO JECT-p  ro j ec t -name , 

LIBRARY=library-name , 

UNIT- unit -name, 

PASSWORD-ob j  ect-section-password , 

OBJECT-  [YES1  ,  ] 

[NO  j  ] 

PROCEDURE-special-compile-procedure  ,  ] 

INPOOL-  (compool  1  ^ 

[(compool  - 1 ,...,  compoo  1-9  )f  1 
OUTPOOL-  [YES'S  '  | 

[NO  f  J 

PROJl-f irst-project-to-search , ] 

PR0J2-second-proj ect-to-search , ] 


PR0J9=ninth-library-to-aearch , ] 
LIBl-first-library-to-search, ] 
LIB2-second-library-to-search, ] 


LIB9-ninth-library-to-aearch] 


*  * 
** 
** 
** 

*  A 

*  * 


** 
*  * 


[  it  it 

[  ** 
[  *  * 


[  *  * 


*Also  see  Appendix  1. 
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The  values  for  the  COMPILE  par 


t 


project-name 


library-name 


unit-name 


object-section- 

paaaword 


OBJECT-YES 


apecia 1-compile 
procedure 


name  of  first  project  to  search 
for  SOURCE  units  and  name  of 
projsct  to  be  used  for  resulting 
OBJECT  unit ,  if  OBJECT-YES; 
value  for  PR0J1. 

name  of  first  library  to  search 
for  SOURCE  units  and  name  of 
library  to  be  used  for  resulting 
OBJECT  unit,  if  OBJECT-YES; 
equivalent  to  value  of  LIB1. 

name  of  top-most  SOURCE  unit  to 
be  compiled;  becomes  name  of 
OBJECT  unit,  if  created;  unit 
must  be  MAIN,  CALLED,  or 
INDEPENDENT  unit-type;  maximum 
length  of  name  is  twelve  characters. 

password  of  OBJECT  section; 
required  if  a  password  was 
assigned  to  the  section  and  if 
OBJECT-YES. 

resulting  OBJECT  module  is 
recorded  in  OBJECT  section  and 
stored  in  PROGRAM  section;  this 
is  the  default  value;  if 
OBJECT-NO,  compiled  module  is 
not  available  for  use. 

the  name  to  be  used  to  Invoke  a 
special  JCL  procedure  to  compile 
the  module,  instead  of  the  name 
of  the  language  associated  with 
the  SOURCE  code;  this  procedure 
must  have  been  previously  stored 
in  the  system. 


coapool 


OUTPOOL-YES 


f irst-pro ject-to- 
search 


second-pro Ject-to- 
search 


ninth-project-to- 

aearch 

f irst-library-to- 
search 


second-1 ibrary-to- 
aearcb 


3 


A 

1 

: 

the  naaa  of  a  previously  assembled 
coapool  syabol  table (a)  (JOVIAL 
compiler  ONLY) . 

two  modules  are  stored  In  the 
OBJECT  section  (COMPOOL  syabol 
table,  resulting  OBJECT  module); 

If  OUTPOOL-NO  only  the  OBJECT 
module  la  stored  (JOVIAL  compiler 
ONLY)  . 

equivalent  to  value  for  PROJECT; 

If  both  are  entered,  the  last  one 
will  be  used.  Also  name  of  project 
where  object  unit  will  be  stored  if 
OBJECT-YES. 

see  subsection  3.2.2  for  a  dis¬ 
cussion  of  a  multi-library  search. 


equivalent  to  value  for  LIBRARY; 

If  both  are  entered,  the  last  one 
will  be  used.  Also  name  of  library 
when  object  unit  will  be  stored  If 
OBJECT-YES. 

see  subsection  3.2.2  for  a  dis¬ 
cussion  of  a  multi-library  search. 


ninth-library-to- 

search 

The  following  example  Invokes  a  series  of  COMPILES  for  JOVIAL 
units : 


**  PARAM 
**  COMPILE 
**  COMPILE 
**  COMPILE 


PROJ-FHACD129 ,LIBR-NEWCODE 
UNIT-POOLA , OUTPOOL-YES 
UNIT-POOLB , OUTPOOL-YES 
UNIT-MAINJV , INPOOL- (POOLA,POOLB) 


Units  POOLA  and  POOLS  contain  JOVIAL  data  declarations.  The 
specifying  of  OUTPOOL-YES  results  In  the  generation  of  a  COMPOOL 
symbol  table  for  each  unit.  When  the  unit  MAINJV  Is  compiled, 
the  previously  assembled  symbol  tables  are  made  available  to  the 
JOVIAL  compiler  for  searching. 
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The  following  example  will  Invoke  e  compile  of  e  nodule  using 
e  nulti-librery  search: 

**  PARAM  PRO J-FHACD128 , LIBR«NEWCODE 

**  COMPILE  UNIT-TIPTOP, 

**  PROJ2-FHACD147.LIB2-PROVEN 

Since  TIPTOP  is  written  in  Structured  COBOL  (SCOBOL) ,  the 
SCOBOL  precompiler  will  process  the  units,  starting  with 
TIPTOP  and  working  down  through  all  INCLUDE  statements.  As 
each  INCLUDE  statement  is  picked  up,  the  libraries  ere  searched 
for  the  named  unit.  NEUCODE  is  searched  first  end  then  PROVEN. 
As  each  INCLUDEd  unit  is  found,  the  code  is  reed  and  added  to 
the  total  stream  of  code  which  will  be  processed.  Nested 
INCLUDES  are  resolved  in  place  so  that  the  flnrl  module  is  in 
proper  logical  order.  Comments  are  placed  in  the  listing  to 
shown  the  project  and  library  where  each  unit  wee  found.  If 
a  unit  is  s  SOURCE  stub,  a  DISPLAY  statement  is  Inserted  in  its 
place.  Original  unit-line-numbers  ere  placed  in  columns  1 
through  6  of  the  compiler  input,  for  programmer  reference. 

The  procedures  which  are  provided  with  the  PSL  system  are  listed 
in  Appendix  D.  See  subsection  3.2.4  for  a  discussion  about 
spawned  jobs. 


3.4.6 


CREATE 


After  *  project  le  Initialized,  the  CREATE  Function  Is  used  to 
build  sections  In  e  user's  llbrsry.  Section  options  ere 
selected  et  this  tlae.  For  e  HGMT  section,  the  aanageaent 
plsn  unit  Is  lnltlellzed.  A  detailed  description  of  the 
structure  of  e  section  is  given  in  Appendix  A. 


**  CREATE 
** 

** 

[** 

[** 


PROJECT-project-naae , 
LIBRARY-library-nane , 
SECTlON-sec t lon-nsae , 
PASSWORD-aection-passvord ,  ] 
FMS*fas -entry , ] 


Section 

options : 

** 

COMPRESS- 

HO  ,] 

YES  ] 

** 

MGMTDATA- 

HO  ,] 

YES  ] 

** 

SPCHECK- 

HO  ,] 

YES  ] 

** 

SPLENGTH- 

50_ 

nbr-of -lines 

** 

KEY*plan- 

unit-key] 

,] 

1 


The  values  for  the  CREATE  Function  ere: 

project-naae  -  neae  of  project  under  which  the 

section  will  be  built. 

llbrary-naae  -  neae  uaed  to  uniquely  identify 

e  group  of  stenderd  sections  under 
e  project;  aaxlaua  length  of  seven 
characters;  one  of  eech  of  the 
stenderd  eactlone  aey  be  built 
under  a  given  library. 

sectlon-neae  -  neae  of  eectlon;  auet  be  one  of 

the  standard  section  neaes  (JOB, 
LIME,  LOAD,  NCNT ,  OBJECT,  PDL , 
SOURCE,  TEST,  TEXT,  USER  ,  PROGRAM)  . 
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section-password  -  password  which  will  be  required 

In  order  to  write  into  the 
section;  maxlmua  of  twelve 
characters . 

fms-entry  -  used  to  enter  FMS  paraaeters  for 

section  file;  default  size  is  ten 
TRACKS  reserved  and  aaxlaua. 

The  options  which  nay  be  selected  for  a  section  are  described 
below: 

a.  COMPRESS  -  This  option  Is  appropriate  only  for  the 
JOB,  LINK,  MGMT ,  PDL ,  and  SOURCE  sections.  If 
option  is  selected,  leading  blanks  are  oaltted  on 
the  file  and  reinserted  upon  retrieval.  Trailing 
blanks  are  always  suppressed.  INDEPENDENT  units 
are  never  compressed,  regardless  of  the  value 
selected  for  this  option. 

b.  MGMTDATA  -  This  option  is  appropriate  for  all 
sections.  See  Figure  3-01  for  a  detailed  list  of  the 
accounting  data  which  aay  be  sccuaulated  for  a  unit 
in  these  sections.  The  iteas  which  are  listed  In 
the  Accounting  Record  are  maintained  whether  or  not 
this  option  Is  selected.  The  Items  In  the  Extended 
Accounting  Record  are  only  maintained  If  MGMTDATA-YES 

c.  SPCHECK  -  This  option  is  appropriate  for  the  PDL 

and  SOURCE  sections  only.  If  the  option  is  selected, 
and  If  the  language  of  a  unit  Is  supported  by  a 
structured-programming  unit-print  facility,  the 
code  of  a  unit  will  be  checked  during  printing  for 
adherence  to  structured-programming  principles. 
Violations  will  be  flagged.  At  present,  only  SCOBOL. 
S JOVIAL  and  SPFORT  are  supported  for  this  option. 

d.  SPLENGTH  -  This  option  la  subordinate  to  the  SPCHECK 
option.  The  value  of  this  option  is  used  during  a 
structured-programming  check  as  the  maximum  number  of 
lines  per  page.  The  default  value  is  50.  Excess 
lines  are  flagged. 
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plan-unit -key  -  Used  only  when  creating  a  MGMT 
aaction;  the  plan-unit-key ,  1£  specified,  will 
subsequently  be  required  to  update  the  aanageaent 
data  plan  unit  with  the  MDPLAM  Function. 
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3.4.7  CSCAN 


The  CSCAN  Function  ie  used  to  scan  for  a  specific  string  of 
data  in  any  unit  of  a  section.  It  will  list  the  unit  naae 
and  corresponding  lines  of  code  for  each  occurrence. 

**  CSCAN  PROJsproject-name , 

**  LIBKARY-library-name , 

**  SECTIOH-sec tion-naae , 

**  STRING-charac ter-str ing 

The  values  for  the  CSCAN  Function  sre: 

project-name  -  naae  of  the  project  containing 

the  section  to  be  scanned. 

library-name  -  naae  of  the  library  containing 

the  section  to  be  scanned. 

sectlon-naae  -  naae  of  the  section  to  be 

scanned . 

character-string  -  the  specific  character  string 

to  search  for,  enclosed  in 
quotes  if  special  characters 
occur  within  the  string.  See 
Section  3.4  for  details  on  when 
quotes  are  required;  maximum  of 
48  characters. 

An  exaaple  of  a  CSCAN  Function  is: 

**  PARAM  PROJ-FHACD129.LIBR-NEWCODE, SECTION-JOB 

**  CSCAN  STRING-"ADUN" 


3.4.8  DOCUMENT 

The  DOCUMENT  Function  le  used  to  print  documentation  stored 
in  a  library  in  the  form  of  program  design  language,  struc¬ 
tured  source  code,  text,  etc.  Thus  this  function  can  be  used 
with  units  which  are  in  card-image  format;  that  is,  units  in 
the  SOURCE,  PDL ,  LINK,  JOB,  TEST,  MGMT ,  and  TEXT  sections. 
Output  details  are  provided  on  Subfunction  cards  (HEADER,  TEXT, 
EJECT,  and  SPACE)  which  follow  the  DOCUMENT  card. 


**  DOCUMENT 

PROJECT-pro ject-name , 

** 

LIBRARY- library-name , 

** 

SECTION-sect ion-name , 

** 

LSPACE- line -spacing , ] 

** 

PAGE-  fNO  1  ] 

Vpage-nbrJ  ,j 

** 

PLINES-lihes-per-page , ] 

** 

START-star t-line-nbr , ] 

** 

USPACE-unlt-apaclng , ] 

** 

LADJUST-  (YES  [  1 

The  values  for  the  DOCUMENT  parameters  are: 

project-name  -  name  of  project 

library-name  -  name  of  library 


section-name 


name  of  section;  must  be  SOURCE, 

PDL,  LINK,  JOB,  MGMT,  TEST,  or 
TEXT 


line-spacing 


page-nbr 


the  number  which  represents  the 

line  spacing  required  for  text; 
the  number  1  represents  single 
spacing  of  text;  2  represents 
double  spacing,  etc.,  the  default 
value  is  1  (single  spacing) . 

the  starting  page  number  of  the 

document;  the  default  is  1;  if  the 
printing  of  page  numbers  is  to 
suppressed,  the  word  NO  is  to  be 
used  instead  of  a  number. 


linea-per-page 


maximum  number  of  lines  which 

can  be  printed  on  a  page  (in¬ 
cluding  headers  and  blank  lines) ; 
the  default  is  50. 
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•V 


left-adjust 


atart-line-nbr 


unit-spacing 


specified  whether  document  text 
la  to  be  left  adjusted  to  left 
margin  of  page  or  to  be  placed 
In  center  of  the  132  character 
line. 

the  starting  line  number  for 
any  printing  on  a  page,  whether 
Header  lines  or  text;  the 
default  value  is  1. 

the  number  which  represents  the 
line  spacing  between  units. 

The  number  1  represents  single 
spacing  (the  next  unit  immediately 
follows  the  previous  line) ,  2 
represents  double  spacing,  etc.; 
if  emitted.  It  is  set  equal  to 
the  value  for  LSPACE. 


Optional  subfunction  cards  are  used  to  provide  details  for  the 
DOCUMENT  output  requirements.  The  optional  keywords  for  the 
DOCUMENT  function  (LSPACE,  PAGE,  PLINES,  START,  USPACE,  LADJUST) 
may  also  be  used  on  the  three  subfunction  cards  (HEADER,  TEXT, 
and  SPACE)  but  not.  on  the  EJECT  card. 


In  addition  to  the  five  previously  mentioned  optional  keywords, 
the  values  for  the  Subfunction  keywords  are: 


**  HEADER 


(source  cards 
**  TEXT 
(source  cards 
**  SOURCE 
**  EJECT 


HPRINT-  j~NO  1 
]YESj 

HSPAC E-header -spacing 
for  new  Header  may  be  placed  here) 
UNIT-unlt-name 

for  additional  text  may  be  placed  here) 
LINES-nbr -of -spaces 

(no  keywords  are  associated  with  the 
EJECT  Subfunction) 


HPRINT  -  NO  Is  used  to  stop  the  print  of 

Header  llnea  which  had  prevloualy 
been  input;  YES  la  used  to  restart 
the  printing  of  Header  lines  which 
had  been  suppreased  by  a  prior 
HPRINT-NO  keyword.  Vhen  SOURCE 
cards  for  a  new  header  are 
entered,  the  default  value  Is  YES. 
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header -spacing 


header  source  cards 


unit-name 


text  source  cards 


nbr-of-spaces 


The  number  which  represents  the 
line  spacing  between  the  last 
Header  line  and  the  flrat  line  of 
text  on  a  page.  The  number  1  is 
single  spacing  (text  immediately 
followa  the  header) ;  2  represents 
double  spacing,  etc. 


The  provided  cards  are  printed 
at  the  top  of  each  new  page  on 
the  DOCUMENT  Function  output. 

A  maximum  of  ten  cards  may  be 

used  as  Input;  single  spacing  j 

is  assumed  on  output,  therefore 

a  blank  line  may  only  be  placed 

in  the  header  by  Including  a  j 

blank  card.  i 

I 

Name  of  the  unit  which  is  to  be  j 

printed;  the  unit  must  be  present  5 

in  the  section  and  must  not  be  a  I 

Stub  unit.  If  the  unit  desired 
is  located  In  a  different  library 
and/or  section,  then  a  new  DOCUMENT 
Function  card  must  be  used.  Data  ' 

stored  in  a  unit  will  be  printed 
after  any  source  card  text  Is 
printed. 


Any  number  of  source  cards  may 
be  placed  In  the  run  stream 
following  a  TEXT  card;  If  the 
TEXT  card  contains  the  optional 
UNIT  parameter,  the  named  unit 
will  be  printed  after  the  source 
card  text. 

Actual  number  of  blank  lines 
desired . 
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3.4.9  EXECUTE 

The  EXECUTE  Function  Invokes  the  execution  of  a  user's  program. 
The  program  Itself  may  be  retrieved  by  the  PSL  system  In  one 
of  the  following  forms: 


a.  A  load  module  from  the  PROGRAM  section 

b.  A  series  of  one  or  more  object  modules,  which  are 
selected  as  a  result  of  collector  control  cards  In 
a  unit  of  the  LINK  section  and  which  will  be 
processed  by  the  Collector. 


The  user's  Job  control  cards  for  execution  of  his  program  are 
stored  in  a  unit  in  the  JOB  section.  Special  PSL  flags  are 
placed  in  these  cards  to  direct  the  system  in  the  placement 
of  additional  file  references. 


**  EXECUTE 

PROJECT-pro ject-name , 

** 

LIBRARY»llbrary-name , 

** 

JOB* j ob-unlt-name >  * 

ft** 

LOAD"load-unit-name , ]  "1  only  one  will  be 

u** 

LINK"link-unit-name , ] J  used 

[** 

PROJl-f irst-project-to-search , ] 

[** 

PRO J2"second-project -to -search, ] 

e 

[** 

•  a 

PR0J9«ninth-project-to-search, ] 

[  ** 

LIBl-f lr 8 t -library- t o-8 ear ch , ] 

[** 

LIB2-sy  ond-library-to-eearch ,  ] 

• 

[  ** 

• 

L IB9"n in th-llbrary-to -search] 

The  values  for  the 

execute  parameters  are: 

project-name 

name  of  the  first  project  to 
p  search  for  the  JOB,  LOAD,  or 

LINK  units;  equivalent  to 

, 

value  for  PR0J1. 

library-name 

name  of  the  first  library,  to 
search,  as  above;  equivalent 

* 

to  LIB1. 

job-unit-name 

-  name  of  unit  containing  the  ueer' 

* 

JCL  for  execution  of  his  program; 
see  discussion  of  PSL  flags  below 

\ 
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load -unit-name 


link-unit -name 


f irat-proj  ecl- 
to-search 


second-pro Ject- 
to-search 


ninth-pro ject- 
to-aearch 

f irst-library- 
to-aearch 


name  of  unit  containing  the  system- 
loadable  program;  only  one  unit- 
name  will  be  used  from  the  LOAD  or 
LINK  sections;  LOAD  unit  created 
by  LINK  Function;  default  is 
load-unit-neme  equals  job-unit-name. 

name  of  unit  containing  Collector 
control  cards  to  load  OBJECT 
modules  for  execution;  the  load 
module  is  not  saved;  see  LINK 
Function  for  description  of  PSL 
OBJECT  INCLUDE  cards  (which  are 
used  with  collector  control  cards) 
and  for  discussion  on  use  of  LINK 
unit . 

equivalent  to  value  for  PROJECT;  if 
both  are  entered,  the  last  one  will 
be  used. 

see  subsection  3.2.2  for  a 
discussion  of  a  multi-library 
search . 


equivalent  to  value  for  LIBRARY; 
if  both  are  entered,  the  last  one 
will  be  used. 


second-library-  -  see  subsection  3.2.2  for  a 

to-search  discussion  of  a  multi-library 

search. 

• 

ninth-1 ibrary- 
to-search 


The  job  control  cards  stored  in  a  unit  in  the  JOB  section  will 
be  retrieved  by  the  PSL  system  and  used  as  the  basic  input 
stream  for  the  execution.  However,  some  Information  must  be 
added  to  this  input  stream  by  the  PSL  system.  In  order  to 
direct  the  placement  of  this  information,  apeclal  PSL  flag- 
words  are  inserted  in  columns  73  through  80  (left-justified) 
on  the  user's  control  cards. 


For  the  EXECUTE  Function,  the  user  Inserts  the  vord  EXECUTE  on 
the  first  card  of  his  execution  activity: 

Col  Col 

1  73 

8XQT  EXECUTE 
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3.4.10  INDEX 


The  INDEX  Function  prints  s  ststus  report  for  s  section.  The 
report  contsins  information  pertsinlng  to  the  section  as  a 
whole,  ss  well  as  s  listing  of  the  index  for  the  section. 

An  example  of  s  Section  Index  Report  is  shown  in  Figure  3-02. 

**  INDEX  PROJECT-project-nama, 

**  LIBRARY-library-naee 

**  SECTION-aect ion-name 

The  values  for  the  INDEX  Function  are: 

project-name  -  name  of  project. 

library-name  -  name  of  library. 

section-name  -  name  of  section  for  which  report 

is  printed. 


I 

l 

I 


3.4.11  INITIAL 


Under  the  FSL  tyttu,  a  user  stores  progress  end  date  In 
discrete  units,  within  sections  of  a  library,  under  a  project. 
A  project  suat  be  Initialised  before  libraries  are  built  under 
It.  The  project  Identification  number  is  used  as  the  name  of 
the  project.  The  PSL  Function  INITIAL  establishes  the  project 
as  a  PSL  project  and  prepares  an  Index  for  library-sections 
under  the  project. 

**  INITIAL  PROJECT-project-name, 

[**  FMS-fms-entry ] 

The  vslues  for  the  INITIAL  Function  are: 

project-name  -  name  for  project  to  be 

initialised  under  the  PSL  system 
maximum  of  twelve  characters. 

used  to  enter  FMS  parameters  for 
random  Index  file  for  project; 
default  else  Is  two  tracks 
reserved  and  maximum. 


fms-entry 


The  JCL  Function  enables  the  user  to  Introduce  JCL  cards  Into 
the  input  stream  of  a  subsequently  spawned  job.  The  Function 
is  not  required  in  the  basic  use  of  the  PSL  system,  but 
provides  the  flexibility  of  using  additional  Exec  8  control 
cards  in  conjunction  with  such  PSL  Functions  as  COMPILE  and 
LINK.  See  subsection  3.2.5  for  a  discussion  of  spawned  jobs. 

**  JCL 

No  keywords  are  associated  with  the  JCL  Function. 

The  following  example  adds  a  new  activity  to  the  spawned  job: 


**  PARAM 

PROJ-UMC1234, LIBR-MYLIB 

**  LINK 

LINK-TIPTOP 

**  INDEX 

SECT-LOAD 

**  JCL 

@PRT,F 

MYFILE. 

@XQT 

MY. JOB 

A  @F  IN  card  should  not  be  placed  in  the  cards  added  with  the 
JCL  Function.  The  PSL  system  will  add  a  @FIN  card  at  the  end 
of  the  last  activity  in  the  spawned  job. 


3.4.13  LINK 

The  LINK.  Function  retrieves  one  or  more  object  module  entries 
from  the  OBJECT  section,  collects  the  corresponding  relocatable 
elements,  end  records  the  nev  absolute  element  in  the  LOAD 
section.  The  resulting  absolute  element  is  stored  as  a  unit 
in  the  PROGRAM  section.  The  name  of  the  LOAD  unit  is  the 
same  as  that  of  the  LINK  unit. 

**  LINK  PROJECT=project-name, 

**  LIBRARY“library-name , 

**  PASSWORD “load-section- pas sword, 

[**  LINK*link-uni t-name , ] 

[**  OBJECT=object-unit-name, ] 

t  **  PROJ l»f ir s  t-pro j ec  t- to-search , 3 

[**  PR0J2“second-project-to-8earch, ] 


PROJ9=ninth-project-to-search,33 
LIBl»first-library- to-search, 3 
LIB2“second-library-to-search, 3 


[  **  LIB9**ninth- library- to- search 3 

The  values  for  the  LINK  parameters  are: 


proj  ect-name 


library-name 


load-section- 

password 


1 in k-uni t-name 


object-unit-name 


name  of  first  project  to  search 
for  LiNK  unit  when  required  and 
name  of  project  to  be  used  for 
same  resulting  LOAD  unit; 
equivalent  to  value  for  PR0J1. 

name  of  first  library  to  search 
for  LINK  unit  when  required  and 
name  of  library  to  be  used  for 
storing  resulting  LOAD  unit; 
equivalent  to  value  for  LIB1. 

password  of  LOAD  section;  not 
required  if  password  not  assigned 
to  section. 

name  of  unit  containing  collector 
control  cards. 

name  of  the  unit  recorded  in 
the  OBJECT  section. 


L 


f iret-project-to- 

search 


eecond-project-to- 

scarch 


ninth-pro j act- to- 

aearch 

firat-library-to- 

search 


second-library- to- 
search 


ninth-1 ibrary-to- 
search 

The  LINK  unit  auat  meet  the  following  requirements: 

The  collector  control  cards  are  scanned  for  special  PSL  OBJECT 
INCLUDE  carda,  which  are  formatted  as  follows: 

INCLUDE  object-unit-name 

The  word  INCLUDE  may  start  in  any  column.  The  object-unit-name 
must  terminate  before  column  73  and  must  be  preceded  by  at  least 
one  space.  The  OBJECT  module  referenced  by  object-unit-name  is 
located  in  the  single  or  multi-libraries  declared  with  the 
PROJECT,  LIBRARY,  etc.,  keywords.  The  PSL  system  changes  each 
Include  card  to  an  IN  statement  with  the  proper  PROJECT  file 
and  relocatable  element.  The  resulting  LOAD  unit  will  be  given 
the  same  name  as  the  LINK  unit.  If  an  OBJECT  module  is  not 
found  in  the  library,  a  dummy  OBJECT  module  (OBJECT  stub)  is 
generated  with  the  object-unit-name  of  the  OBJECT  INCLUDE  card. 
If  the  module  is  called  during  execution,  the  OBJECT  stub  prints 
the  message: 

STUB  (object-unit-name)  CALLED 

Also,  if  the  first  OBJECT  INCLUDE  card  in  the  unit  is  a  stub, 
a  MAIN  stub  will  be  generated. 


equivalent  to  value  for  PROJECT; 
if  both  are  entered,  the  last 
one  will  be  used. 

see  subsection  3.2.2  for  a 
discussion  of  a  multi-library 
search . 


equivalent  to  value  for  LIBRARY; 
if  both  are  entered,  the  last 
one  will  be  used. 

see  subsection  3.2.2  for  a 
discussion  of  a  multi-library 
search . 
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3.4.14  MDCOLLECT 

The  MDCOLLECT  Function  in  used  to  collect  management  data  in 
accordance  with  requirements  of  the  Management  Data  Plan 
(provided  for  through  use  of  the  MDPLAH  Function)  and  the 
management  data  format  specifications  (provided  for  thorough 
use  of  the  MDFORMAT  Function).  Automatically  maintained 
management  data  is  derived  from  MDPLAN-speclf led  source  code 
modules  while  manually  input  data  is  assembled  from  MDPLAN- 
specifled  unitt  established  and  updated  through  use  of  the 
MDUPDATE  Function. 


**  MDCOLLECT  PROJBCT-pro ject-name , 

**  LIBRARY- library-name  , 

**  PASSWORD-sect ion-password , 

**  KEY-unit -key , 

**  ARCHIVE-  lYESl 

LNO  J  ,  , 

**  RECYCLE-  fYEJfi 

J  J 

**  PGMR-programmer-name , ] 

**  PROCEDURE-special-collectlon-procedure ,  ] 

The  values  for  the  MDCOLLECT  parameters  are: 


project-name 

library-name 

section-password 


unit-key 


ARCHIVE 


name  of  project, 
name  of. library. 

password  which  was  assigned  when 
the  management  section  was  created; 
not  required  if  a  password  was  not 
assigned . 

key  to  be  assigned  (when  MDCOLLECT 
Function  is  first  used)  or  key 
which  was  assigned  (when  MDCOLLECT 
Function  is  subsequently  used); 
not  required  if  a  key  was  not 
assigned  when  MDCOLLECT  was  first 
used . 

if  not  specified,  archiving  of 
the  previously  collected  data  will 
depend  upon  parameters  established 
in  the  relevant  format  level  units; 
if  YES  is  specified,  archiving  will 
occur  as  permitted  for  each  format 
level;  if  HO  is  specified,  archiving 
will  not  occur. 
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RECYCLE 


programmer -name 


special- col lection 


if  not  specified,  recycling  of 
cyclic  data  accumulations  will 
depend  upon  parameters  established 
in  the  relevant  format  level  units; 
if  YES  is  specified,  recycling  will 
occur  for  all  referenced  format 
levels  and  archiving  may  occur 
(unless  otherwise  specified) ;  should 
MO  be  specified,  recycling  will  not 
occur  nor  will  archiving  (unless 
otherwise  specified)  . 

name  to  be  placed  in  accounting 
record;  maximum  of  twelve  characters 
default  is  userid  for  job. 

the  name  to  be  used  to  Invoke  a 
special  JCL  procedure  to  collect 
management  data,  Instead  of  the 
standard  procedure  stored  in  the 
system.  This  special  procedure 
must  also  have  been  previously 
stored  in  the  system  in  order  to 
be  Invoked;  (see  Installation 
Manual) . 
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3. A. 15  MDFORMAT 

The  MDFORMAT  Function  Is  used  to  provide  the  ability  to  add, 
change,  or  delete  management  data  format  units  In  the  Management 
(MGMT)  Section.  A  unit  listing  Is  automatically  produced  after 
MDFORMAT  Is  completed. 


**  MDFORMAT 


PROJECT =project-name , 
LIBRARY «=llbrary-name  , 
PASSWORD-password  , 

KEY-key, 

SYSTEM 
SUBSYSTEM  ( 

LEVEL=  ^MODULE  , 

JOB 

[unit 

MOD-modlf ication-number , ] 
rADD  1 
0P=  CHANGE  l 

DELETE  f  , 

JIOVE  J 

CYCLB«cycle-per iod , ] 
OLDPROJ-old-project-name , ] 
OLDLIB-old-library-name , ] 
ARCHIVE-  IYE ,1 


i'»oS)  ■] 


[**  PGMR-programmer-name ] 

The  values  for  the  MDFORMAT  Function  are: 


!  L 
l 


pro j  ec  t-name 
library-name 
sec  t lon-password 


unit-key 


name  of  management  data  project. 

name  of  management  data  library. 

password  which  was  assigned  to 
MGMT  Section  when  It  was  created; 
not  required  if  a  password  was 
not  assigned. 

when  OP-ADD,  key  to  be  assigned 
to  the  unit  for  use  in  subsequent 
updates.  When  OP-CHANGE,  DELETE 
or  MOVE,  key  assigned  when  unit 
was  added;  not  required  If  no 
keyword  was  assigned  when  unit 
was  added. 


L 


mod  if tea t ion-number 


OP 


LEVEL 


cycle-period 


old-project-name 


old-library-name 

ARCHIVE 


pro 


Humber  to  be  checked  against 
modification  level  in  accounting 
record;  a  listing  of  the  unit  Is 
printed  but  no  update  takes  place 
if  values  do  not  match;  maximum 
value  of  999. 

The  operation  code,  indicates 
whether  a  format  unit  Is  to  be 
added,  deleted,  changed  or  moved. 

The  default  is  CHANGE.  If  MOVE 
is  specified,  then  OLDPROJ  or 
OLDLIB  keywords  is  required. 

The  format  level  for  which 
management  data  items  are  defined. 

A  number  (not  to  exceed  two  digits) 
indicating  the  minimum  calendar-day 
period  constituting  a  cumulative 
data  cycle.  Default  value  is  zero, 
indicating  that  the  cycle  period 
is  undefined. 

Name  of  project  from  which  the 
format  is  to  be  moved. 

Name  of  library  from  which  the 
format  is  to  be  moved. 

Archiving  of  data  items  defined 
by  the  format  unit  is  permitted  if 
the  value  is  YES;  archiving  is  not 
permitted  if  the  value  is  NO.  The 
default  (if  LEVEL-SYSTEM)  is  YES, 
otherwise  the  default  is  NO. 

Name  to  be  placed  in  accounting 
record;  maximum  of  twelve  characters 
default  is  userid  for  job. 


The  following  examples  show  how  to  add  a  format  unit  under  one 
project  library  and  subsequently  move  it  to  another: 


**  PARAM  PRO J- SYSTEM , LIBR-PSL 

**  MD FORMAT  OP-ADD .LEVEL-SYSTEM 

(source  transactions  follow) 
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**  PARAM  PR0J-UMC1234 .LIBR-MYLIB, 

**  MDFORMAT  OP-MOVE .LEVEL-SYSTEM  , CYCLE-28 , 

**  OLDP-SYSTEM.OLDL-PSL 

Note  that  the  cycle  period  is  updated  subsequent  to  the  move 
(as  would  the  archive  indication  if  it  were  specified)  . 

The  following  example  will  move  the  level  format  specified 
on  the  old  project  and  old  library  to  the  management  data 
project  and  library: 

**  PARAM  PROJ-UMC1234 , LIBR-NEWCODE 

**  MDFORMAT  OP-MOVE, 

**  0LDPR0J-UMC0111 , OLDLIB-OLDCODE 

Format  specifications  are  entered  as  input  data  in  card 
columns  1-72.  Figure  3-13  contains  the  definition  of  the 
format  specifications. 

Appendix  J  contains  a  SOURCE  Function  printout  of  the  MDCR 
Format  units  delivered  with  the  PSL  system  and  stored  in  the 
system  project  PSL  library  MGMT  section.  These  formats  may 
be  moved  to  a  user-designated  MGMT  section  and  either  sub¬ 
sequently  modified  or  used  "as  is"  to  facilitate  the  initial 
utilization  of  the  MDCR  capability. 


i 


i 

? 


* 
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Data  N a me 


*- 


s;  . 


Card  Column 


1  Operation  Code 


1 

2-4 

Item 

Number 

5 

Data 

Source  Code 

6-8  Referenced  Item 

(If  column  5 
not-falank) 

6-8  Repeated  Item 

Code 

(If  column 
5-blank) 

9  Manual  Input 


110-11  Maximum  Length 

(if  column 
5=blank) 

I. 


Figure  3-13.  Management 


Data  Description 

I  (Insert) 

M  (Modify) 

D  (Delete) 

a  three  digit  numeric; 
zero  is  not  permitted. 

b  (manual  input  data) 

*  (an  item  in  the  same  format) 

S  (an  item  in  subsystem  format) 
M  (an  item  in  module  format) 

J  (an  item  in  job  format) 

A  (an  item  in  the  accounting 
item  list)  -  refer  to 
Tables  3-1  and  3-2. 

$  (an  item  in  the  special  item 
list)  -  refer  to  Table  3-2. 

a  three  digit  numeric  that 
matches  an  item  number  in 
the  source  format  or  list) 

specified  as  "RPT"  for  manual 
input  items  only. 


5 (no  edit) 

A(alphabetic) 

N (numeric) 

two  digit  numeric  from  01  to  48; 
defaults  to  48  unless  column  9=N 
numeric  values  will  default  to 
08  which  is  the  maximum  length 
that  a  numeric  value  can  be 
assigned  . 


Data  Format  Specifications 
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Card  Column  Data  Mama 


Data  Description 


9-11 


Summary  Function 
(If  column  5 
oot-blanlt) 


AVG  (computes  average  Input 
value) 

MAX  (computes  maximum  input 
value) 

TTL  (computes  total  of  input 
values)  -  default  value 


9-11 


12-23 


25-72 


Cyclic  Function 
(if  column  5*>*) 


Item  Marne 


Item  Label 


CYC  (computes  the  cumulative 
change  in  value  of  the 
Referenced  Item  specified 
In  columns  6-8) 

mnemonic  name  of  defined  items 
must  be  left  justified  and 
start  vlth  an  alphabetic 
character.  No  embedded 
blanks  are  permitted. 

a  descriptive  label  used  in 
output  reports  to  fully 
Identify  the  reported  item 
value . 


Figure  3-13.  Management  Data  Format  Specifications 

(Continued) 
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Item 

Referenced 

Unit  Accounting  Data  Input 

|  1 

Unit  Type  Name 

Unit  Line  Size 

Including  Unit  Name 

A004 

Version  Number 

A005 

Modification  Number 

A006 

Date  Unit  Originated 

A007 

Originator  Name 

A008 

Date  Last  Update 

A009 

Time  Last  Update 

AOIO 

Unit  Language 

AOll 

Include  Count 

A012* 

Total  Lines  in  Unit 

A013* 

Structured  Program  Error  Code 

A014* 

Lines  Added 

A015* 

Lines  Changed 

A016* 

Lines  Deleted 

A017* 

Total  Lines  Input 

A018* 

Lines  Input  in  Cycle 

A019* 

Lines  Copied 

A020* 

Total  Number  of  Updates 

A02 1* 

Updates  in  Cycle 

A022* 

User  tfork  Area 

*  -  Extended  MGMT  Data 


Table  3-1.  Unit  Format  References 
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Item 

Referenced 


Applicable  Format/Item  Category: 
_ Data  Input _ 

Module  Format/Summary  Input  Items 


A101 

Lines  in  Unit 

A102 

Unit  Lines  Added 

A103 

Unit  Lines  Changed 

A104 

Unit  Lines  Deleted 

A105 

Unit  Lines  Input  -  Total 

A106 

Unit  Lines  Copied 

A10  7 

Unit  Updates  -  Total 

Module  Format/Numer ic  Items 

A201 

Compiles  -  Total 

A20  2 

Real  Unit  Count 

A203 

Stub  Unit  Count 

A204 

Structured  Program  Unit  Error  Count 

Module  Format/Non-Numeric  Items 

A301 

Top  Unit  Type 

A302 

Date  Top  Unit  Originated 

A303 

Originator  Name 

A304 

Top  Unit  Language 

A305 

Date  Module  Last  Updated 

Non-Unit  Formats/Special  Items 

$001 

Subordinate  Element  Count 

$002 

Start  Cycle  Date 

$003 

Cycle  Duration  (days) 

$004 

Current  Date 

$005 

End  Cycle  Indication  ( No-0 ,  Yes-1) 

Table  3-2.  Module  Accounting  and  Special  Item  References 
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When  a  User  wishes  to  generate  a  report  other  than  those 
produced  by  the  PSL,  he  uses  the  MDPRINT  Function  to  provide 
the  printing  capability. 

**  PARAM  PROJ=UMC1234  ,LIBR=*MYLIB 

**  MDFORMAT  OP -MOVE , LEVEL=  SYSTEM , CYCLE=  2 8  , 

**  OLDP" SYSTEM ,OLDL=PSL 

Note  that  the  cycle  period  is  updated  subsequent  to  the  move 
(as  would  the  archive  indication  if  it  were  specified). 

The  following  example  will  move  the  level  format  specified  on 
the  o  '  project  and  old  library  to  the  management  data  project 
and  library: 

**  PARAM  PR0J-UMC1234 , LIBR-NEWCODE 

**  MDFORMAT  OP=MOVE, 

**  0LDPR0J  =  UMC0111  .OLDLIB-OLDCODF. 

Format  specifications  are  entered  as  input  data  in  card  columns 
1-72.  Subsection  3.4.15  contains  the  definition  of  the  format 
specif ica  t ions . 

Appendix  J  contains  a  source  listing  of  the  MDCR-FORMAT  units 
delivered  with  the  PSL  system  and  stored  in  the  System  project 
PSL  library  MGMT  Section.  These  formats  may  be  moved  to  a 
user-designated  MGMT  Section  and  subsequently  modified  or 
immediately  used  to  facilitate  initial  utilization  of  the  MDG? 
capability. 
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V. 


3.4.16  MDPLAN 

The  MDPLAN  Function  is  used  to  modify  the  contents  of  the 
Management  Data  Plan  (MDPLAN)  unit  which  is  automtically 
established  (without  data  content)  when  a  Management  Section 
is  created.  A  unit  listing  is  automatically  provided  for  the 
indicated  plan  unit.  Modification  details  are  provided  on 
Subfunction  cards  following  the  MDPLAN  card  exactly  as 
prescribed  for  the  CHANGE  Function. 


** 

** 

*  it 

*  * 
[  *  it 

[  *  * 


MDPLAN 


PROJECT  =  project-name  , 
LIBRARY- library-name , 

PASS WO RD»section-pass word, 
KEY=p lan- unit-key, 

MOD “modification- level ,  ] 
PGMR-prog rammer -name ] 


The  values  for  the  MDPLAN  parameters  are: 


project-name 


Name  of  project. 


library-name 


Name  of  library. 


section-password  -  Password  which  was  assigned  when 

the  management  section  was  created; 
not  required  if  password  was  not 
ssigned . 


plan-uni t-key 


modification-level 


Key  assigned  when  management 
section  was  created;  not  required 
if  a  key  was  not  assigned. 

Number  to  be  checked  against  the 
modification  level  in  the  unit 
accounting  record;  no  update 
takes  place  if  values  do  not 
match;  maximum  value  of  999. 


pr o gr amme r -name  —  Name  to  be  placed  in  accounting 

record;  maximum  of  twelve  char¬ 
acters;  default  is  userid  for  job. 

The  Subfunctions  which  are  used  to  alter  the  contents  of  an 
MDPLAN  unit  are  described  under  the  CHANGE  Function.  The 
following  example  shows  an  appropriate  procedure  for  providing 
the  initial  input  to  that  unit: 
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AA 

PARAM 

PROJ-UMC1234 , LIBR-NEtf CODE 

** 

CREATE 

SECTION-MGMT , KEY-SKELETON 

A* 

MDPLAN 

KEY-SKELETON 

A  A 

I  A-0 

(source  cards  are  initially  Inserted  at  beginning  of  unit 
card  columns  1-72  are  used  for  data  input) 

Sample  input: 

SYSTEM-BIGTOP 

SUBSYS-SUB1,PROJ-UMC001,LIBR-TEST 
MODULE “MODI A 
MODULE-MOD 2A.LIB2-PROVEN 

SUBSYS-SUB2 , PROJ2-UMC002 .LIB2-INTEG 
M0DULE-M0D2A ,M0DULE-M0D2B 

Project/library  keyword  value  specifications  are  cumulative 
and  may  be  changed  at  any  point  in  the  plan  input  sequence. 
Project  and  library  keyword  values  may  be  nulled  by  omitting 
the  keyword  value  specification  (e.g.,  PRO Jn- , LIBn-> .  Key¬ 
word/value  specifications  for  a  given  input  line  can  have  no 
Imbedded  blanks;  however,  blank  lines  may  be  Inserted  as 
needed . 

Keyword  specification  may  begin  in  any  column  as  long  as  the 
given  keyword  and  value  specification  is  wholly  contained  on 
a  single  card.  Project  and  library  specification  applying  to 
a  given  module  may  be  given  prior  to  the  occurrence  of  the 
module  element  or  given  "in  continuation"  of  the  module 
element  specification  by  using  commas  to  separate  successive 
project  and  library  keyword  specification  that  apply  to  that 
module.  Verification  of  the  plan  syntax  is  performed  when 
the  MDCOLLECT  Function  is  used. 


V. 
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3.4.17  MDPRINT 

The  MDPRINT  Function  Is  used  to  print  management  data  reports. 
Keywords  for  the  MDPRINT  Function  consists  of  both  general 
keywords,  which  are  processed  by  the  MDPRINT  processor,  and 
specific  report  keywords,  which  are  passed  to  a  spawned  report 
generator.  See  subsection  3,2.5  for  a  discussion  of  spawned 
Jobs. 


**  MDPRINT 

*  it 

** 

** 

[  ** 

[  it  it 

PRO JECT=pro j ect-name , 

LIBRARY=library-name, 

SECT ION=sec tion-name , 

REPORT  =  r epor  t-code , 

PROJl"first-project-to-search,] 

PR0J2*second-project-to-search,] 

[  ★  ★ 

[  ** 

[  ** 

PR0J9"ninth-project-to-search, ] 
LIBl-first-library-to-search, ] 
LIB2**second-library-to-search,  ] 

[  ★* 

LIB9-ninth-library-to-search] 

values  for  the 

general  keywords  for  the  MDPRINT  Function 

pr oj  ec  t-name 

-  Name  of  the  first  project  to  search; 

equivalent  to  value  for  PR0J1. 

library-name 

-  Name  of  first  library  to  search; 

equivalent  to  LIB1. 

sec  tion-name 

-  Name  of  section,  if  appropriate; 

in  the  case  of  PS  report  should 
be  PDL  or  SOURCE. 

r epor  t-code 

Two-letter  code  to  select  report. 

firs  t-pr o j  ec  t 
search 

-to-  -  Equivalent  to  value  for  PROJECT; 

if  both  are  entered,  the  last  one 
will  be  used. 
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second-project-to  -  See  subsection  3.2.2  for  a  dis- 
search  cusslon  of  s  multi-library  search. 

ninth-project-to- 

sesrch 

f irst-librsry-to-  -  Equivalent  to  value  for  LIBRARY; 
aesrch  if  both  ere  entered,  the  lest  one 

will  be  used. 

second-librsry-to-  -  See  subsection  3.2.2  for  a  dis- 
sesrch  cusslon  of  a  multi-library  search. 


ninth- library- to- 
search 


Program  Structure  Report 


Keywords  for  Progrsm  Structure  (PS)  report; 


**  UNIT-beglnnlng-unlt-name, 
**  CALL-  (NO  1  , 

VyesJ 

**  NEST-  (50  \ 

\nbrj 


The  values  for  the  PS  keywords  are: 


beginnlng-unlt-name  -  Name  of  unit  with  which  to  begin 

the  hierarchical  search;  not 
required  to  be  a  top-unit. 


CALL-YES  -  If  option  is  selected,  a  PS  report 

will  be  generated  for  each  unit 
referenced  by  a  CALL  statement  in 
the  code  of  the  units  scanned. 


NEST-nbr  -  If  option  is  selected,  the  hier- 

archicsl  search  will  not  scan  units 
for  which  the  INCLUDE  statements 
are  nested  at  levels  deeper  than 
this  value;  the  default  of  50  is 
the  PSL  limit  for  nested  INCLUDE 
statements . 
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The  PS  report  begins  with  the  unit  which  Is  nsned  on  the  Function 
card  and  develops  a  hierarchically  nested  and  Indented  list  of 
all  units  which  are  referenced  by  an  INCLUDE  statement,  either 
In  the  originally-requested  unit  or  In  units  which  are  themselves 
INCLUDEd  In  the  hierarchical  program  structure.  Units  which  are 
referenced  by  a  CALL  statement  are  alao  printed  with  the 
appropriate  Indentation  In  the  list,  but  they  are  not  automatically 
searched  for  lower  levels  of  INCLUDE  or  CALL  statements.  Statistical 
and  organisation  Information  la  printed  for  each  unit.  An 
alphabetically-arranged  list  of  all  referenced  units  follows  the 
hierarchical  list.  An  example  of  a  Program  Structure  Report  Is 
shown  In  Figure  3-04. 

Example : 

**  MDPRINT  PRO JECT-UMC12  34  , LIBRARY -MYL IB  , 

**  UNIT-TIPTOP ,REP0RT«PS 
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SUBSYS-NO 


If  option  Is  selected,  subsystem 
level  reports  will  be  suppressed. 


MODULE-NO 

JOB-NO 

UNIT-YES 

beginning-element 

name 


HISTORY-ALL 

HISTORY- (SERIES . . .) 

HISTORY- (DATES. . . ) 

start-series 


If  option  is  selected,  module 
level  reports  vill  be  suppressed. 

If  option  is  selected,  job  level 
reports  vill  be  suppressed. 

If  option  is  selected,  unit  level 
reports  vill  be  enabled. 

Name  of  report  level  element  with 
which  to  begin  the  hierarchical 
output;  a  report  will  be  produced 
for  the  specified  element  (if  j 

present)  and  for  subordinate 
level  elements  In  the  hierarchy, 
provided  that  reports  are  not 
suppressed  at  the  subordinate 
level(s).  The  ouput  of  all 
other  report  elements  vill  be 
suppressed . 

If  this  option  is  selected,  all 
archived  date  collections  in  the 
MGMT  Section  will  be  processed 
for  output. 

If  this  option  is  selected,  the 
archived  data  collections  included 
in  the  designated  series  will  be 
processed  for  output. 

If  this  option  is  selected,  the 
archived  data  collections  whose 
data  was  collected  within  the 
calendar  period  defined  by  the 
specified  dates  will  be  processed 
for  output. 

The  serial  number  of  the  first 
archived  data  collection  to  be 
processed;  minimum  vslue-0. 
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The  aerial  number  of  the  last 
archived  data  collection  to 
be  proceaaed;  maximum  value=999. 

The  earlieat  date  of  data 
collection  that  will  be  processed 
for  output;  date  format  is  MMDDYY. 

The  latest  date  of  data  collection 
that  will  be  processed  for  output; 
date  format  la  MMDDYY. 


3.4.18  MDUPDATE 


After  required  format  units  are  added  to  the  MANAGEMENT  section, 
the  MDUPDATE  Function  Is  used  to  originally  Introduce  data 
Into  a  management  data  unit,  modify  the  contents  of  a  management 
data  unit,  or  delete  a  management  data  unit.  Modification 
details  are  provided  by  the  operation-code  and  the  Subfunction 
cards  (DELETE,  MODIFY,  and  INSERT)  which  follow  the  MDUPDATE 
card.  New  management  data  follows  either  the  MDUPDATE  card  for 
the  add  operation  or  the  INSERT  and  MODIFY  Subfunction  cards  for 
the  change  operation.  Identification  of  management  data  items 
to  be  deleted  follow  the  DELETE  Subfunction  card. 

**  MDUPDATE  PROJECT-proJect-name  , 

**  LIBRARY-library-name , 

**  PASSWORD-sect lon-password , 

**  UNIT*management-da ta-unit , 

LEVEL* unit-level,] 

[**  MOD-modlf ication-level ,  ] 

**  KEY*unit-key 

**  OP-operation-code 

The  value  for  the  MDUPDATE  parameters  are: 

project-name  -  Name  of  project. 

library-name  -  Name  of  library. 

section-password  -  Password  which  was  assigned  when 

the  MGMT  section  was  created; 
not  required  If  a  password  was 
not  assigned. 

management-data-  -  Name  of  management  data  unit  to 

unit  be  processed. 

unit-level  -  Level  of  management  data  unit; 

must  be  SYSTEM,  SUBSYSTEM,  MODULE, 
or  JOB;  required  only  if  opera¬ 
tion-code  is  ADD. 

modification-level  -  Number  to  be  checked  against 

modification  level  in  unit 
accounting  record;  a  listing  of 
the  unit  Is  generated  but  no 
update  takes  place  if  values  do 
not  match;  maximum  value  999. 


unit-key 


Key  which  Is  assigned  to  unit 
when  It  Is  added  to  MGMT  section 
not  required  If  a  key  is  not 
assigned. 

operation-code  -  The  operation  to  be  performed  by 

the  MDUPDATE  Function;  must  be 
ADD,  CHANGE  or  DELETE. 

The  Subfunction  cards  are  used  only  when  the  change  operation 
Is  specified  on  the  MDUPDATE  card. 

**  INSERT 

(new  management  data) 

**  MODIFY 

(management  data  to  be  modified) 

**  DELETE 

(management  data  Identifiers  to  be  deleted) 

The  Subfunctions  need  not  be  In  a  particular  order.  The 
management  data  will  be  edited,  verified,  and  sorted  before 
the  management  Input  unit  Is  processed  by  the  MDUPDATE 
Function.  All  Subfunctions  may  be  abbreviated  to  four 
characters  or  to  one  character. 

The  MDUPDATE  Function  updates  a  management  data  unit  by  pro¬ 
cessing  data  Items  supplied  in  the  Input  data  and  by  creating 
a  new  copy  of  the  unit.  After  the  MDUPDATE  processing  has 
terminated,  a  listing  of  the  unit  Is  automatically  generated 
showing  the  actual  contents  of  the  unit  In  the  library. 

The  following  examples  show  how  a  user  may  add,  change,  or 
delete  the  contents  of  a  management  data  unit: 

**  PARAM  PROJ-UMC1234 , LIBR-NEWCODE 

**  MDUPDATE  UNIT-TIPTOP-MANAGEMENT-DATAA, OP-ADD, 

**  LEVEL-SYSTEM, KEY-HIDDEN 

(new  management  data) 

**  MDUPDATE  UNIT-TIPTOP-MANAGEMENT-DATA, OP-CHANGE, 

**  KEY-HIDDEN 

**  M 

(management  data  to  be  modified) 

**  x 

(new  management  data  to  be  Inserted) 

**  d 

(management  data  to  be  deleted 
**  MDUPDATE  UNIT-TIPTOP-MANAGEMENT-DATA, OP-DELETE 

**  KEY-HIDDEN 


1 

Unit  must  not  exist  prior  to  add  operation. 
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Input  data  nay  utilize  card  coluana  1-72  to  provide  manual 
Input  data.  The  forma  In  which  theinput  data  may  be  sub- 
mltted  are  aa  follow*  (no  Imbedded  blank  permitted) : 

**  I  or  **  M  (for  a  non-repeated  Item) 
ltem-ldent*item-value 

**  M  (for  a  repeated  Item) 

Item-lden t , repea t-nbr “item-value 

**  D  (for  a  non-repeated  item) 

Item-ldent 

**  D  (for  a  repeated  item) 
ltem-ident , repea t-nbr 

in  which  the  following  deacriptiona  apply: 

item-ldent  -  The  format  item  number  o r 

item-name . 

item-value  -  The  value  with  which  the  identi¬ 

fied  item  la  to  be  updated  (it 
ahould  conform  to  the  format  Edit 
specification) . 

sequence-nbr  -  A  two  digit  number  assigned  to 

repeated  occurrences  of  a  given 
item-ldent  by  MDUPDATE  when  a 
format  specified  RPT  item  is 
multiply  submitted  following  an 
Insert  subfunction. 

An  RPT  specified  item  (see  MDFORMAT  Function)  is  one  for  which 
multiple  values  may  be  submitted.  Each  Inserted  item  value  is 
identified  when  a  sequence  number  one  higher  than  the  previously 
Inserted  value  for  that  same  item.  In  order  to  modify  or  delete 
a  specific  occurrence  of  the  repeated  item,  the  corresponding 
sequence  number  must  be  obtained  from  the  unit  listing  whose 
format  is  illustrated  in  Figure  3-13.  As  noted,  the  sequence 
number  (in  columns  10-11)  immediately  follows  the  item  number 
(in  columns  7-9). 
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3.4.19  MDXCHECK 

After  a  management  data  unit  haa  been  added  to  the  MGMT  section, 
the  MDXCHECK  Function  la  uaed  to  add,  change  or  delete  exception 
checking  apeclf Icatlona  within  the  exlating  management  input  unit. 
Modification  details  are  provided  by  the  Subfunction  cards  (DELETE, 
MODIFY,  and  INSERT)  which  follow  the  MDXCHECK  card.  New  and 
revised  exception  checking  specifications  follow  the  INSERT  and 
MODIFY  Subfunction  cards,  respectively.  Identification  of 
exception  checking  specifications  to  be  delted  follow  the  DELETE 
Subfunction  card. 


**  MDXCHECK 

PRO JECT-pro J  ec  t-name , 

** 

LIBRARY-library-name , 

** 

PASS WORD -section-pas sword 

** 

UN IT-manag ement -data -unit 

[** 

MOD-modif icat ion-level,] 

[** 

KEY-unit-key ] 

The  values  for  the 

MDXCHECK  parameters  are: 

project-name 

- 

Name  of 

project. 

library-name 

- 

Name  of 

library  where  MGMT 

section 

exist . 

section-pasaword 


management -da ta- 
unit 


mod  if  lea t ion -level 


unit-key 


Password  which  was  assigned  when 
the  MGMT  section  was  created; 
not  required  if  a  password  was 
not  assigned. 

Name  of  management  data  unit  to 
be  processed;  unit  must  have 
been  added  to  the  MGMT  section 
prior  to  MDXCHECK  processing. 

Number  to  be  checked  against 
modification  level  in  unit 
accounting  record;  a  listing  of 
the  unit  is  generated  but  no 
update  takes  place  If  values  do 
not  match;  maximum  value  999. 

Key  which  was  assigned  to 
management  data  unit  when  it  was 
added  to  MGMT  section;  not 
required  if  a  key  was  not 
assigned . 


i 

f 

I 

v* 
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The  Subfunction  cards  are  required  to  follow  the  MDXCHECK  card. 

**  INSERT 

(new  exception  checking  data) 

**  MODIFY 

(exception  checking  data  to  be  modified) 

**  DELETE 

(exception  checking  data  identifiers  to  be  deleted) 

The  Subfunctions  need  not  be  in  a  particular  order.  The  exception 
checking  data  will  be  edited,  verified  and  sorted  before  the 
management  data  unit  is  processed  by  the  MDXCHECK  Function.  All 
Subfunctions  may  be  abbreviated  to  four  characters  oi  to  one 
character . 

The  MDXCHECK  Function  updates  an  existing  management  data  unit 
by  processing  exception  checked  data  items  against  format- 
defined  data  items  and  creating  a  new  copy  of  the  management 
input  unit. 

After  the  MDXCHECK  processing  has  terminated,  a  listing  of 
the  management  input  unit  is  automatically  generated  showing 
the  actual  contents  of  the  unit  in  the  library.  The  following 
examples  show  how  a  user  may  add,  change  or  delete  exception 
checking  specifications  in  a  management  input  unit: 

**  PARAM  PROJ-UMC1234.LIBR-NEWCODE 

**  MDXCHECK  UNIT-TIPTOP-MGMT-DATA1 .KEY-FIRST 

**  INSERT 

(new  exception  checking  data) 

**  M 

(exception  checking  data  to  be  modified) 

**  D 

(exception  checking  data  identifiers  to  be  deleted) 

Input  data  cards  may  utilize  columns  1-80  to  provide  exception 
check  specifications.  The  form  in  which  the  input  data  must 
be  submitted  for  added  and  modified  exception  check  specifi¬ 
cations  1 s  as  follows: 

item  1  item  2:  V  percent,  date ,  f remark] 

where  non-underlines  delimiters  are  required  as  represented 
and  underlined  items  are  to  be  provided  in  accordance  with 
the  descriptions  below. 


1Unit 


must 


already  exist 


prior 


to  MDXCHECK  Function  processing. 
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3.4.20  MOVE 


The  MOVE  Function  moves  a  unit,  from  one  project  to  another, 
from  one  library  to  another,  or  within  a  library. 


**  MOVE 

PRO  JECT-r  eceiving-pro  j'ec  t  -name  , 

** 

LIBRARY-receiving-library-name , 

** 

SECT ION -sec  t ion -name , 

** 

PAS SWORD- receiving -sect ion-pas sword , 

** 

UNIT-  f r eceiving-unit-name|  , 

\ALL  J 

** 

KEY-rece i v in g -unit -key , 

[ 

** 

OLDPROJ-old-project-name , ] 

l 

*  * 

OLDLIB-old-librar y-name ,] 

[ 

*  * 

OLDUNIT-old-unit-name , ] 

[ 

** 

REPLACE-  (NO  \  ,  ] 

t 

\YES  j  ] 

[ 

** 

FMS-f ms-entry , ] 

[ 

** 

PGMR-programmer-name ] 

The  values  for  the  MOVE  Function  are: 

receiving-project-name  -  name  of  project  to  which  unit 

is  moved. 

receiving-library-name  -  name  of  library  to  which  unit 

is  moved. 

section-name  -  name  of  both  receiving  section 

name  and  old  section  name;  must 
be  JOB,  LINK,  PDL ,  SOURCE,  TEST 
or  TEXT. 

receiving-section-  -  password  of  receiving  section; 

password  not  required  if  one  was  not 

assigned . 

receiving -unit-name  -  name  of  unit  to  which  unit  is 

moved;  if  UNIT-ALL,  the  PSL 
system  will  attempt  to  move  all 
units  in  the  section  from  old- 
library-name  to  recelvlng- 
library-name ;  see  below  for 
rules  affecting  a  MOVE. 

r  eceiving-unit-key  -  key  which  was  assigned  to 

receivlng-unit-nsme  when  it  was 
added  to  the  section;  ignored  if 
UNIT-ALL;  applicable  only  if 
REPLACE-YES . 
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old -pro j  ect-name 

name  of  project  from  which  unit 
la  to  be  moved. 

old -library-name 

■  1 

-  name  of  library  from  which  unit 

la  to  be  moved;  required  If 
UNIT-ALL. 

old-unit-name 

-  name  of  unit  from  which  unit  Is 

to  be  moved;  required  if  neither 
old-project-name  nor  old-library- 
name  Is  used. 

REPLACE-YES 

-  if  PSL  system  finds  that  a  real 

unit  already  exists  in  receiving 
section,  unit  will  not  be  moved 
unless  YES  option  has  been 
declared;  NO  is  default;  stubs 
will  be  replaced  under  either 
option . 

f ms-entry 

-  used  to  enter  FMS  parameters  for 

unit  file.  If  unit  Is  INDEPENDENT; 
default  sixe  for  INDEPENDENT  unit 
file  is  1  reserved  track,  2  maximum 
tracks . 

programmer -name 

-  name  to  be  placed  In  accounting 

record  of  receiving  unlt(s); 
default  is  userid  for  job. 

The  simplest  kind  of  MOVE  involves  a  single  unit  being  moved 
to  a  unit  which  does  not  exist.  In  this  case,  the  unit-type 
and  the  cumulative  accounting  Information  is  moved,  as 
appropriate,  with  the  unit. 

If  a  single  unit 
a  real  unit,  the 

Is  moved  to  a  unit  which  already  exists  as 
MOVE  will  not  take  place  unless: 

a.  REPLACE-YES  vaa  declared. 


b.  The  receiving-unit-key  matches  the  key  found  In  the 
receiving  unit.  If  one  was  assigned. 

c.  The  unit-type  of  the  receiving  unit  Is  consistent 
with  the  unit-type  of  the  old-unit  (both  are  top- 
units,  or  both  are  lncluded-unlts) . 

If  the  MOVE  takea  place,  the  resulting  unit  will  retain  the 
unit-type  of  the  receiving-unit.  The  accounting  Information 
of  the  receiving-unit  will  be  updated  appropriately  and 
INCLUDES  will  be  resolved  within  the  receiving  section. 
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When  UNIT-ALL,  an  old-library-name  and  a  nev-llbrary— name 
must  be  declared.  The  PSL  system  vlll  attempt  to  MOVE  each 
unit  In  the  old  library /section  to  the  receiving  library/ 
section.  The  rules  described  for  a  single-unit  MOVE  vlll  be 
applied  for  each  unit  MOVE.  Since  key  checking  la  not 
possible  in  this  case,  a  unit  vlll  not  be  moved  if  the 
receiving  unit  van  assigned  a  key. 

A  MOVE  Function  does  not  alter  the  status  of  the  old  location. 
Disposition  of  the  old  copy  is  at  the  discretion  of  the  user. 

For  a  move  involving  an  independent  unit,  if  the  space 
assignment  for  the  receiving  unit  is  insufficient  to  hold  all 
source  data  from  the  old-unit,  the  PSL  vlll  abort.  In  this 
case,  the  user  should  use  the  PURGE  Function  to  purge  the 
receiving  unit  from  the  section  and  rerun  the  job  using  the 
FMS  keyvord  on  the  MOVE  Function  to  assign  a  larger  size  to 
the  Independent  unit  file. 


3.4.21  PARAM 


This  Function  Is  used  to  enter  high-level  parameters  which 
apply  to  a  series  of  subsequent  PSL  Functions.  Once  the  values 
are  established,  they  remain  in  effect.  All  of  the  values, 
except  security  clssslf lestion  code,  may  be  replaced  by  using 
the  keyword  again,  on  another  Function  card  for  which  it  is 
valid . 


**  PARAM 
** 

** 

** 

** 

** 


[PROJECT»pro J ec t-name , ] 
[LIBRARY-library-name , ] 
[SECTION-sectlon-name , ] 
[PASSWORD-sec tion-password , ] 
[PCMR-programrner-name ] 


Each  of  these  keywords  will  provide  subsequent  Functions  with 
values.  The  user  should  refer  to  the  descriptions  of  those 
Functions  to  understand  how  the  value  will  be  used.  All 
keywords  are  optional  with  the  PARAM  Function. 
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3.4.22  PERFORM  Function 


The  PERFORM  Function  Invokes  a  designated  procedure  contained 
in  a  user's  project  library.  The  Job  control  cards  constituting 
this  procedure  specify  the  programs  and  files  required  for  a 
particular  user  operation.  The  PERFORM  Function  enables  a 
non-PSL  program  operation  to  Interface  with  PSL  data  files  by 
using  flagword  data  (paced  in  columns  73  throtffgh  80  of  a  job 
control  card)  to  direct  the  addition  of  a  PSL  data  file 
reference.  The  subject  data  for  that  reference  is  taken  from 
user-provided  keyword  input  values  and  the  subsequently  modified 
job  control  procedure  is  written  to  the  spawned  job  file. 

PROJECT-pro j ect-name , 

LIBRARY  -  library-name, 

PASSWORD  •  section-password 
PROCEDURE  -  user-procedure-name, 

UNIT  ■  unit-name,] 

KEY  -  unit-key,] 

FMS  ”  f ms-entry,] 

FILEl  ■  first-user-file, 

FILE2  -  second-user-file. 


**  PERFORM 
** 

*  * 

[  ** 

[** 

[  ** 

[** 

[  ** 


[**  FILE9  -  ninth-user-file 

The  values  for  the  PERFORM  parameters  are: 

project-name  -  name  of  project. 

library-name  -  name  of  library. 

section-password  -  password  of  section(s)  to  be 

written  by  user  procedure;  not  j 

required  if  a  password  was  not  j 

assigned  to  the  sectlon(s)  when 
created.  f 

user-procedure-name  -  name  of  unit  in  JOB  section  of 

designated  project  and  library 
which  contains  all  or  part  of  the 
JCL  required  for  a  user-program 
operation . 
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unit-naae 


unit-key 


fms-entry 


first-user-file 


second-user-file 


naae  of  unit  in  PSL  section (s) 
referenced  by  flagwords  in  the 
designated  user-procedure. 

key  to  be  assigned  (when  unit  or 
file  Is  first  written)  or  key  which 
was  assigned  (when  unit  is  sub¬ 
sequently  written) ;  not  required  if 
a  key  was  not  assigned  when  unit 
was  first  written. 

used  to  enter  the  FMS  paraaeters 
for  Independent  units/files  which 
are  referenced  by  flagwords  in  the 
designated  user-procedure. 

naae  of  an  Independent  file  that  is 
created  and  added  to  the  directory 
aaintalned  in  the  USER  section  of 
the  designate  project  and  library 
for  access  by  user  prograas  only. 

naaes  of  additional  files  as  may  be 
required  by  the  designated  user 
procedure . 


ninth-user-file 
Flagword  Card  Foraet 

User-procedure  flagwords  are  left-justified  to  coluan  73  of  a 
job  control  card.  The  prescribed  format  of  the  flagged  job 
control  card  is  as  follows: 


Col 

1 

@ASG 


flagword  [ , access-code] 
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The  following  is  a  Hat  of  valid  flagvords,  subdivided  into  three 
data-ref erence  categories. 


PSL  Section 

User  File 

Card 

JOB 

FILE1 

CARDS 

LINK 

F1LE2 

LOAD 

FILE3 

MGMT 

FILE4 

OBJECT 

FILE5 

PDL 

FILE  6 

SOURCE 

FILE7 

TEST 

FILE8 

TEXT 

USER 

FILE9 

All  flagworda  except  CARDS  must  be  accoapanied  by  one  of  the 
following  access  codes: 

R:  read  permission  requested 

W:  write  permission  requested 

/:  read  and  write  permission  requested 

Flagwords  in  the  PSL-sectlon  category  are  paired  vith  the  UNIT 
keyword  input  value  to  reference  a  unit  in  the  noted  PSL  section, 
while  in  the  user-file  category,  flagwords  are  corresponded  with 
the  matching  keyword  input  to  reference  non-PSL  data  files  that 
are  accessed  by  user  programs  only.  The  PERFORM  Function 
dynamically  creates  the  referenced  files  (as  needed)  through 
Interface  with  the  Sperry  Univac  Exec  8  System  provided  that 
the  required  PSL  section  is  created  using  STANDARD»NO  as  a 
section  option. 

Replacement  Card  Format 

The  job  procedure  card  on  vhlch  the  flagvord  "CARDS"  appears 
will  be  replaced  by  the  following  card: 

Col  Col 

1  73 

@DATA , I  CARDS 

User-provided  card  input  data  that  follows  the  PERFORM  Function 
keyword  input  specification  will  be  Inserted  after  the  above 
9DAIA  card  and  succeeded  by  a  @END  card. 


I 


i 
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The  job  procedure  card  on  which  a  valid  PSL-section  or  user-file 
flagword  appears  will  be  replaced  by  a  card  in  the  following 
format : 


Col  Col 

1  73 

@ASG,A  file  reference.  flagword  specification 

User  File  Directory 

Files  which  are  named  through  user-file  keyword  input  values  and 
designated  for  operations  through  user-file  flagwords  are 
accounted  for  in  a  section  directory  as  established  in  the 
USER  section  of  the  keyword-referenced  project  and  library.  The 
CREATE  Function  must  be  utilized  to  establish  the  referenced  USER 
section  prior  to  the  execution  of  the  given  PERFORM  Function. 

Only  that  space  required  to  maintain  accounting  data  for  the 
files  need  be  requested  when  creating  the  USER  section.  The 
space  required  to  create  user  files  is  obtained  through  the 
PERFORM  Function,  when  needed,  as  directed  by  the  accompanying 
FMS  keyword  input  values  or  determined  by  the  FMS  default 
parameters  assigned  by  PSL. 

Although  user-file  contents  are  not  directly  accessed  by  PSL 
operations,  it  is  necessary  for  the  PERFORM  Function  to  initiate 
user  files,  the  TERMINATE  and  PURGE  Functions  to  delete  user 
files,  and  the  INDEX  Function  to  list  user  files.  Neither  the 
BACKUP  option  of  the  TERMINATE  Function  nor  the  BACKUP  Function 
operate  to  save  user-file  data  in  the  referenced  USER  section. 
Standard  Univac  1100  utilities  are  available,  however,  that  can 
be  used  to  save  the  contents  of  user  files  should  such  backup 
be  required. 
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3.4.23  PRECOMPILE  Function 

The  PRECOMPILE  Function  retrieves  units  from  the  SOURCE  section 
and  Invokes  the  appropriate  precompiler.  The  unit  name  is  the 
name  of  the  top-moat  source  unit  of  the  module  which  Is  to  be 
compiled.  The  processing  which  Is  Invoked  by  the  PRECOMPILE 
Function  depends  upon  the  language  of  the  unit.  Under  the 
current  PSL  system,  procedures  exist  to  process  the  SCOBOL 
(Structured  COBOL),  SPFORT  (Structured  FORTRAN),  SJOVIAL 
(Structured  JOVIAL)  and  unstructured  ASMG,  COBOLG,  FORTRANG, 
and  JOVIALG  languages.  Procedures  to  precompile  additional 
languages  may  be  added  to  the  system.  Procedures  are  auto¬ 
matically  invoked  by  the  language-name,  or  may  be  specifically 
invoked  with  the  PROCEDURE  keyword. 


**  PRECOMPILE 

PROJECT-proj  ect-name , 

** 

LIBRARY-library-name  , 

** 

UN IT-uni t-name  , 

[  ** 

PROCEDURE* special -precomp lie -procedure,] 

[  ** 

PROJl*f irst-pro ject-to-search, ] 

[** 

PR0J2*second-pro ject -to -search , ] 

• 

[  ** 

PR0J9-nlnth-library-to-search, ] 

[** 

LIBl-f ir at -llbrary-to -search, ] 

[  ** 

LLB2* second- libr ary-to -sear ch , ] 

[  ** 

LIB9*ninth-llbrary-to-sear ch] 

The  values  for  the  PRECOMPILE  parameters  are: 


project-name 


library-name 


name  of  first  project  to  search 
for  SOURCE  units;  equivalent  to 
value  for  PR0J1. 

name  of  first  library  to  search 
for  source  units;  equivalent  to 
value  of  LIB1. 


« 


i 


4 

4 


i 
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unit-name 


spec  la 1 -precomp lie 
procedure 


first-project-to- 

search 


name  of  top-most  SOURCE  unit  to 
be  compiled;  unit  must  be  MAIN, 
CALLED,  or  INDEPENDENT  unit-type; 
maximum  length  of  name  is  6 
characters  . 

the  name  to  be  used  to  invoice  a 
special  JCL  procedure  to  pre¬ 
compile  the  module,  instead  of 
the  name  of  the  language  asso¬ 
ciated  with  the  SOURCE  code;  this 
procedure  must  have  been  previously 
stored  in  the  system;  (see 
Installation  Manual). 

equivalent  to  value  for  PROJECT; 
if  both  are  entered,  the  last 
one  will  be  used. 


second -project-to- 
search 


ninth-project-to- 

search 

first-1  ibrary-w>- 
search  *► 


second  -  ytbrary-to- 
search 


see  subsection  3.2.2  for  a 
discussion  of  a  multi-library 
search. 


equivalent  to  value  for  LIBRARY; 
if  both  are  entered,  the  last 
one  will  be  used. 

see  subsection  3.2.2  for  a 
discussion  of  a  mult  1  — library 
search. 


ninth-library-to- 

search 
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The  following  example  will  invoke  a  precompile  of  a  module 
uaing  a  multi-library  search: 

**  PARAM  PROJ-FHACD129 , LIBR-NEWCODE 

**  PRECOMPILE  UNIT-TIPTOP 

**  PROJ2-FHACD147 .LIB2-PR0VEN 

Since  TIPTOP  is  written  in  Structured  COBOL  (SCCBOL) ,  the 
SCOBOL  precompiler  will  process  the  units,  starting  with 
TIPTOP  and  working  down  through  all  INCLUDE  statements.  As 
each  INCLUDE  statement  is  picked  up,  the  libraries  are  searched 
for  the  named  unit.  NEWCODE  is  searched  first  and  then  PROVEN. 
As  each  INCLUDEd  unit  is  found,  the  code  is  read  and  added  to 
the  total  stream  of  code  which  will  be  processed.  Nested 
INCLUDES  are  resolved  in  place  so  that  the  final  module  is  in 
proper  logical  order.  Comments  are  placed  in  the  listing  to 
show  the  project  and  library  where  each  unit  was  found.  If  a 
unit  is  a  SOURCE  stub,  a  DISPLAY  statement  is  inserted  in  its 
place.  Original  unit-line-numbers  are  placed  in  columns  1 
through  6  of  the  precompiler  output,  for  programmer  reference. 

The  procedures  which  are  provided  with  the  PSL  system  are 
listed  in  Appendix  D.  The  job  cards  In  these  procedures 
which  occur  before  the  compile  activity  (noted  by  the  flagword 
COMPILE  starting  in  column  73,  when  present)  are  output  to  the 
spawn  job  file  to  initiate  the  specified  precompile.  See 
subsection  3.2.4  for  a  discussion  about  spawned  jobs. 

The  precompiler  output  will  be  stored  in  the  temporary  file 
denoted  in  the  procedures  as  follows: 

@ASG,T  PO.F///100 

Succeeding  JCL  can  be  added  to  the  spawn  job  file  via  the  JCL 
or  PERFORM  Functions  which  may  utilize  the  temporary  file  as 
input  to  a  succeeding  activity.  The  precompile  activity  may 
insert  an  @USE  PO. .PERMANENT-FILENAME  and  an  @ASG,A  PO.  to 
override  the  @ASG,T  card  which  then  directs  the  precompiler 
output  to  a  designated  permanent  file.  See  subsection  3.4.22 
for  an  example  of  how  the  PERFORM  Function  may  be  used  to 
direct  precompiled  output  to  specified  PSL  storage. 
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3. A. 24  PURGE  Function 

An  individual  unit  la  removed  from  a  library  with  the  PURGE 
Function.  A  user  should  be  aware  that  units  are  also  removed 
from  a  library  when  a  higher  aggregation,  such  as  a  section 
or  library,  is  removed  with  the  TERMINATE  Function. 

PURGE  PROJECT-pro j ec t-name , 

LIBRARY- library -name , 

SECTION-section-name  , 

UNIT-unit-name ,  one  only,  required 
FILE-f ile-name , 

KEY-unit-key 

The  values  for  the  PURGE  Function  are: 

project-name  -  name  of  project. 

library-name  -  name  of  library. 

section-name  -  name  of  section. 

section-password  -  password  which  was  assigned  when 

the  section  was  created;  not 
required  if  a  password  was  not 
assigned . 

unit-name  -  name  of  unit  to  be  purged  from 

the  section  index. 

file-name  —  name  of  file  to  be  purged  from 

the  section  directory. 

unit-key  -  key  which  vaa  assigned  to  unit 

or  file  when  it  was  added  to 
section;  not  required  if  a  key 
was  not  assigned. 

Example : 

**  PARAM  PROJ-UMC1234,LIBR-MYLIB, SECTION-JOB 

**  PURGE  UNIT-TIPTOP , KEY-MYSTERY 

When  INDEPENDENT  files  are  released,  the  FMS  directive  PURGE  is 
used  to  overwrite  the  file  space. 

A  unit  whose  type  is  STUB  may  not  be  removed  from  a  section 
with  the  PURCE  Function.  When  the  last  INCLUDE  statement 
referencing  the  STUB  unit  is  deleted  from  units  in  the  section, 
the  STUB  unit  will  be  automatically  purged  from  the  section. 


** 

** 

** 

** 

** 

** 


T 
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3.4.25  REPLACE  Function 

After  data  has  been  added  to  a  unit,  the  REPLACE  Function  is 
used  to  completely  replace  all  of  the  data  lines  in  the  unit 
Accounting  information  i9  not  re-initialized ,  but  is  updated 
appropriately. 


**  REPLACE 

PROJECT=projec t-name , 

*  * 

LIBRARY=library-name, 

** 

SECTION*section-name, 

*  * 

PASSWORD“section-password, 

** 

UNIT“unit-name , 

[  ** 

KEY-uni t -key ,] 

[  ** 

PGMR-programmer-name  ] 

The  values  for  the  REPLACE  parameters  are: 

project-name  -  name  of  project 


pr  o J  ec  t-name 

library-name  -  name  of  library. 

section-name  -  name  of  section;  must  be  SOURCE, 

PDL ,  JOB,  LINK,  TEST  or  TEXT. 

section-password  -  password  which  was  assigned  when 

the  section  was  created;  not 
required  if  a  password  was  not 
assigned . 

unit-name  -  name  of  unit  to  be  replaced. 

unit-key  -  key  which  was  assigned  to  unit 

when  it  was  added  to  section; 
not  required  if  a  key  was  not 
assigned  . 

The  REPLACE  Function  can  be  used  to  replace  a  real  unit  or  a 
stub.  However,  if  the  unit  does  not  exist  in  the  section  in 
any  form,  an  ADD  Function  must  be  used. 

If  the  space  assigned  to  the  file  for  an  INDEPENDENT  unit  is 
insufficient  to  contain  all  replacement  source  data,  the  PSL 
program  will  ab^rt.  In  that  event,  the  user  should  use  the 
PURGE  Function  to  purge  the  old  unit,  and  the  ADD  Function  to 
put  the  new  source  data  into  the  library  with  a  larger  space 
assignment.  (See  the  description  of  ADD,  Section  3.4.1). 


unit-name 


unit-key 
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3.4.26  RESTORE  Function 

The  RESTORE  Function  la  uaed  to  write  the  contents  of  the 
BACKUP  tape  Into  the  library.  The  Function  may  be  uaed  to 
restore  the  complete  contents  of  the  BACKUP  tape,  or  It  may 
selectively  recover  a  portion  of  the  total  data  tape  at  a 
lower  level. 


**  RESTORE 

PROJECT-proj ect-name , 
LIBRARY-  ("library-name  t  , 

\ALL  J 

** 

SECTION-  j'sec t ion-name  1  , 

Ull  j 

** 

UNIT-  (unit -name  ,1 

\_ALL  J 

** 

PAS SWORD-section-pas sword 

** 

KEY-unit-key , 

[  ** 

FMS-fms-entry ] 

Plus  a  tape  card  with  a  file  name  of  RT ,  as  follows: 

@ASG,A  RT , , r eelnumber 

This  Is  a  Exec  8  control  card  and  follows  the  appropriate 
format.  The  tape  card  must  be  placed  after  the  @END  PSL 
card  at  the  end  of  the  PSL  Function  cards. 

The  values  for  the  RESTORE  parameters  are: 

project-name  -  name  of  the  project;  m-ist  be 

the  same  as  the  project 
Identification  on  the  @RUN 
control  card  for  the  job. 

library-name  -  name  of  the  library;  ALL 

indicates  that  all  libraries  in 
the  project  are  to  be  restored. 

section-name  -  name  of  the  section  to  be 

restored;  ALL  indicates  that  all 
sections  in  the  library  are  to 
be  restored;  presence  of  this 
parameter  Is  considered  an 
error,  if  LIBRARY-ALL. 

unit-name  -  name  of  unit  to  be  restored;  ALL 

indicates  that  entire  section  is 
to  be  restored;  presence  of  this 
parameter  is  considered  an  error 
if  LIBRARY-ALL  or  SECTION-ALL. 
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section-password 


required  for  restore  if  single 
unit  Is  password  was  assigned 
when  section  was  created;  not 
required  if  entire  section  is 
being  restored. 

unit-key  -  required  for  restore  if  single 

unit  exists  in  section  and  key 
was  assigned  to  unit  in  section; 
ignored  if  entire  section  is 
being  restored . 

used  only  when  restoring  units 
for  which  FMS  data  could  not  be 
saved  on  the  backup  tape  by  the 
BACKUP  Function.  This  occurs 
most  frequently  when  backing  up 
a  section  or  unit  which  was 
created  with  a  project  identifi¬ 
cation  other  than  the  one  which 
is  available  on  the  backup  tape, 
it  will  be  used  and  user  supplied 
values  will  be  ignored.  If  FMS 
data  is  not  available  on  the 
backup  tape  and  there  are  no  user 
supplied  values,  the  PSL  default 
values  listed  in  Figure  3-xO  will 
be  used. 

If  all  the  units  in  a  section  are  to  be  restored,  the  section 
muse  exist  and  must  be  empty,  or  the  RESTORE  will  not  be 
processed  for  that  section.  When  a  unit  is  restored,  either 
singly  or  as  part  of  a  section,  all  data  items  for  the  unit, 
including  statistical  data  and  unit-key,  are  replaced  by  the 
data  on  the  RESTORE  tape. 

The  following  example  will  invoke  the  PSL  system  and  RESTORE 
the  SOURCE  section  of  the  NEWCODE  library: 

Col 
1 

t'USE 
('ADD 

**  RESTORE 
*  * 

(:>  END 
0A.SC  ,  A 
OXQT 


PSL.  , DMA*  PSL. 

PSL . RUN 

PRO J=FHACD 1 29, LI BR=N ENCODE, 

S ECT  =  SOURCE , UN  IT  =  ALL 

PSL 

RT, U 9 V, 201020 
PSL . BCTL 


f ms-entry 
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3.4.27  SOURCE  Function 


The  SOURCE  Function  can  be  used  to  print  a  listing  of  any 
unit  which  is  in  card-image  format.  This  Includes  the  unit 
in  the  SOURCE,  PDL,  LINK,  JOB,  TEST,  MGMT ,  and  TEXT  sections. 

If  the  unit  is  from  the  SOURCE  or  the  PDL  section  and  the 
unit  is  written  in  a  supported  structured  language  (Structured 
COBOL,  JOVIAL  and  FORTRAN),  the  structured  code  is  automatically 
indented  for  the  proper  alignment  of  the  structures  on  the 
listing.  This  listing  is  always  provided  when  a  unit  is  added 
to  the  library  or  modified.  The  contents  of  the  unit  may,  on 
option,  be  written  to  tape  or  punched  on  cards.  In  the  latter 
cases,  the  header  information  is  omitted  and  the  code  is 
reproduced  as  it  exists  in  the  unit,  without  automatic  inden¬ 
tation.  An  example  of  a  listing  of  Structured  COBOL  (SCOBOL) 
is  shown  in  Figure  3-03.  An  example  of  a  listing  of  Structured 
FORTRAN  ( SP FORT )  is  shown  in  Figure  3-14. 


**  SOURCE 


PROJECT-pr o j  ec  t-name , 

LIBRARY* library-name , 

SECT ION-sect ion -name , 

UNIT*  [unit-name)  , 

ALL  ) 

MEDIA-  [LIST]  , 

TAPE  } 

1  CARD  j 

NBRLINES-  f50  1,1 

i nbr-lines-per-page|  J 
INDENT*  fYES  I  ] 

\.NO  /  J 


Plus  a  tape  card  with  a  file  name  of  UT ,  if  MEDIA-TAPE: 


@ASG,C  UT,U9V,Z01425 

This  is  a  Exec  8  control  card  and  follows  the  appropriate 
format.  The  tape  card  must  be  placed  after  the  @END  PSL 
card  at  the  end  of  the  PSL  Function  cards.  See  BACKUP  for 
example . 

The  values  for  the  SOURCE  parameters  are: 


pro j  ect-name 


name  of  project. 


I ibr  ar  y-name 


name  of  library. 
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Figure  3-14.  Structured  FORTRAN  Listing 
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section-name  -  name  of  section. 

unit-name  -  name  of  unit  to  be  output;  ALL 

indicates  that  all  units  in 
section  are  to  be  output. 

MEDIA  -  default  will  produce  a  printed 

listing;  TAPE  and  CARD  will 
produce  e  direct  copy  of  the 
data  lines;  TAPE  requires  a 
tape-card;  see  BACKUP  Function 
for  example  of  use  of  tape-card. 

NBRL1NES  -  number  of  lines  of  unit  printed 

on  one  page  (excluding  header 

lines);  value  must  be  in  range  ‘ 

of  1  through  99  and  must  be 

expressed  in  one  to  six  digits; 

default  is  50. 

INDENT  -  may  be  used  to  suppress  auto¬ 

matic  identatlon  if  language  is 
structured;  if  unstructured, 
option  is  Ignored. 

The  following  example  will  list  all  the  units  in  the  JOB  section. 

**  PARAM  PROJECT-FHACD147 , LIBR-PROVEN 

**  SOURCE  SECT-JOB, UNIT-ALL 

The  following  card,  added  to  the  example  above,  will  list  all 

the  units  in  the  SOURCE  section,  with  automatic  indentation 

where  appropriate:  1 

**  SOURCE  SECT-SOURCE, UNIT-ALL 

j 

This  Function  should  not  be  used  in  the  same  job  as  a  BACKUP  \ 

Function  or  a  Termlnate-vlth-BACKUP  Function.  See  description  • 

of  BACKUP  Function.  ; 

If  the  Structured  Programming  Checking  option  was  selected  for  j 

the  section  when  it  was  created  and  if  one  of  these  criteria  is  ; 

not  met,  an  error  flag  will  be  Inserted  in  the  SP  column  on  the  j 

unit  listing.  The  codes  used  for  the  flag  are  as  follows:  ; 
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a.  1  *  Unconditional  transfer  or  addreas  modification 

found  on  line. 

b.  2  »  SP  length  exceeded.  See  CREATE  Function  for 

parameter . 

c.  3  *  Both  of  the  above  were  found  on  the  line. 

d.  4  »  More  than  one  statement  on  line. 

e.  5  *  Conditions  1  and  4  exist  on  line. 

f.  6  *  Conditions  2  and  4  exist  on  line. 

g.  7  *  All  three  error  conditions  on  line. 
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3.4.28  TERMINATE  Function 

This  Function  is  used  to  delete  a  section,  a  library,  or  an 
entire  project.  When  file  space  is  released  by  the  TERMINATE 
Function,  the  FMS  directive  "PURGE"  is  used  to  overwrite  the 
file  space . 

**  TERMINATE  PROJECT-pro j ec t-name , 

**  LIBRARY-  [library-name^  , 

\ALL 


SECTION-  j sec tion-namel 

VALL  J 

BACKUP-  J  NO  \] 


)  YES  J 


Plus  a  tape  card  with  a  file  name  of  UT,  if  BACKUP-YES 


@A  SG  ,  C  UT.U9V.Z01530 

This  is  a  Exc^  8  control  card  and  follows  the  appropriate 
format.  The  tape  caM  must  be  placed  after  the  @END  PSL 
card  at  the  end  of  the  PSL  Function  cards.  See  BACKUP 
for  example. 

The  value  for  the  TERMINATE  parameters  are: 


project-case 


name  of  project' 


1 ibrar y-name 


name  of  library;  ALL  will 
terminate  entire  project  and 
purge  the  project  index. 


sect  ion-name 


name  of  section;  ALL  will 
terminate  entire  library;  not 
required  and  ignored  if 
LIBRARY-ALL. 


BACKUP 


YES  will  produce  a  BACKUP  tape 
of  section(s)  before  deletion; 
default  is  NO. 
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The  following  example  will  delete  the  OBJECT  section  and  save 
the  section  on  a  BACKUP  tape: 


I 

! 

I 

I 

I 

I 


Cm 

1 

OUSE 
i'1  ADD 

**  TERMINATE 

A  * 

UEND 
(3ASG  ,  C 
@  XQT 


PSL.  , DMA*  PSL . 

PSL . RUN 

PRO J=  FHACD 123, LI BR=MYL I B , 
SECT=OBJECT, BACKUP=VES 
PSL 

UT,U9V,Z01620 
PSL. BCTL 


Between  the  @ADD  card  and  the  @END  card,  the  user  may  place  an 
entire  series  of  PSL  Functions,  but  the  user  should  be  aware  of 
the  sequence  in  which  output  is  written  on  the  output  tape, 
if  BACKUP=YES,  See  description  of  BACKUP  Function. 


I 

i 


I' 

I 

l 


t 

t 


1/ 

1. 

I 
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3. 5  Sample  Inputs 

Sample  inputs  are  Included  as  examples  In  the  descriptions  of 
the  Individual  PSL  Functions  in  subsection  3.4.  Appendix  B 
shove  a  sample  input  stream  which  would  build  a  user  library 
of  code  and  execute  the  user  code. 
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0  n«  of  the  principal  objectives  of  the  PSL  Is  to  provide  the 
asset  status  of  a  system  to  the  programmers  and  to  management. 

In  order  to  provide  a  common,  visible  record  of  the  developing 
system,  an  external  (programmer-readable)  version  of  the 
system  is  maintained  in  up-to-date  correspondence  with  the 
Internal  (computer-readable)  version.  The  files  on  disk 
constitute  the  internal  library,  and  the  corresponding  listings, 
properly  filed,  make  up  the  external  library.  See  Figure  3-15. 
Standardized  filing  procedures  have  been  established  to  ensure 
that  the  format  of  the  external  libraries  is  the  same  across 
programming  projects. 

The  responsibility  for  the  maintenance  of  the  library  should 
be  assigned  to  one  person.  In  order  to  make  it  possible  for 
specially  trained  clerical  personnel  either  to  assume  this 
responsibility  or  to  work  directly  with  a  programmer  who  has 
the  responsibility,  the  external  procedures  necessary  to  invoke 
the  PSL  Functions  and  to  file  the  output  have  been  expressly 
designed  to  be  as  straightforward  as  is  practical.  Recommended 
procedures  for  filing  the  output,  in  either  section  notebooks 
or  in  archives,  are  given  below. 

3.6.1  Section  Notebooks 


An  up-to-date  reference  file  ls^ maintained  for  each  section 
under  a  library.  Each  reference  corresponds  exactly  to  the 
section  in  the  internal  library.  The  actual  physical  form  of 
storage  for  a  section  may  vary,  depending  on  the  size  and 
nature  of  the  output  generated  for  a  unit  in  that  section. 

3. 6. 1.1  Card-Image  Data 

The  units  of  the  following  sections  usually  contain  card-image 
data : 


a . 

JOB 

- 

User's  execution  JCL 

b. 

LINK 

- 

Loader  control  cards 

c . 

PDL 

- 

Program  Design  Language  data 

d. 

SOURCE 

- 

Source  program  data 

e . 

TEST 

- 

Test  data 

f . 

TEXT 

- 

Documentation 

8- 

MGMT 

- 

Management  data  from  manual  input 

One  or  more  loose-leaf  notebooks  (11  x  16  1/2)  is  used  for  each 
of  these  sections,  if  the  section  has  been  created  in  the 
library.  When  units  in  these  sections  are  created  or  updated. 
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listings  are  provided  automatically  by  the  PSL  system.  the 
computer  output  Is  burst  and  the  unit  listing  is  filed  in 
alphabetical  order  by  unit  name  in  the  section  notebook..  An 
inder  listing,  vhlch  contains  the  names  and  attributes  of  all 
of  i  units  in  the  section,  is  filed  at  the  beginning  of  the 
notebook.  This  index  listing  is  regenerated  as  necessary  with 
the  INDEX  Function  to  maintain  a  current  and  accurate  picture 
of  the  section. 

For  the  SOURCE  and  PDL  sections,  the  MDPRINT  Function  may  be 
used  to  obtain  a  Program  Structure  Report  for  the  top  units 
in  the  section.  This  report  is  used  to  determine  the  status 
of  the  top-down  development  of  a  program. 

The  Functions  which  affect  the  contents  of  the  notebooks  for 
these  seven  sections  are: 


a . 

ADD 

— 

Add  a  unit 

b. 

REPLACE 

- 

Replace  a  unit 

c . 

CR..NGE 

- 

Change  a  unit 

d. 

MOVE 

- 

Move  a  unit 

e . 

PURGE 

- 

Purge  a  unit 

f  . 

SOURCE 

- 

Print  a  unit 

8- 

INDEX 

- 

Print  a  section  index 

h. 

MDPRINT 

- 

Program  Structure  Report,  Management 
Data  Report,  User  Generated  Report 

i. 

AUTHOR 

- 

Print  specific  programmer's  units  or 
index  of  units 

j. 

DOCUMENT 

- 

Print  a  document 

k . 

MDFORMAT 

- 

Maintain  management  data  formats 

1. 

MDPLAN 

- 

Maintain  management  data  plan 

m. 

MDUPDATE 

- 

Maintain  management  data 

n . 

MDXCHECK. 

- 

Maintain  management  data  exception 
checking 
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3. 6. 1.2  OBJECT  Section 


When  the  COMPILE  Function  is  invoiced,  th.e  compiler  or 
assembler  output  is  filed,  unburst,  in  alphabetical  order  by 
OBJECT  unit  name.  This  is  the  unit-name  of  the  top-most 
SOURCE  unit,  and  is  the  unit  name  declared  on  the  COMPILE 
Function  card.  This  output  may  be  filed  in  notebooks  or 
post-binders,  but  in  many  projects  the  output  is  voluminous 
enough  that  it  is  more  convenient  to  establish  a  file  cabinet 
or  slotted  bookcase  of  suitable  dimensions.  An  up-to-date 
index  is  also  maintained. 

The  Functions  which  may  affect  the  contents  of  the  OBJECT 
section  files  are: 

a.  COMPILE 

b.  INDEX 

3. 6.1.3  LOAD  Section 

When  the  LINK  Function  is  Invoked,  the  Loader  output  listing 
is  filed  unburst  in  alphabetical  order  by  LOAD  unit  name. 

This  name  is  obtained  from  the  LINK  or  OBJECT  unit  name,  which 
was  declared  on  the  LINK  card.  The  LOAD  section  is  maintained 
in  a  loose-leaf  notebook.  A  current  index  is  filed  at  the 
beginning  of  the  notebook.  The  Functions  which  may  affect 
the  content  of  the  LOAD  section  notebook  are: 

a.  LINK 

b.  INDEX 
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3.6.2 


Archives 


An  archives  box  Is  maintained  for  each  section.  When  a  unit 
listing  is  replaced,  the  old  listing  Is  filed  In  the  archives 
box.  In  addition,  the  computer  output  from  a  development 
project  which  does  not  correspond  to  one  of  the  sections  of 
the  library  Is  filed  In  one  of  the  archives  described  below. 
All  archives  are  placed  unburst  in  chronological  order  in  a 
notebook,  post-binder,  or  box  (most  recent  on  top). 

3 . 6 . 2 . 1  Library  Maintenance  Archives 

Those  PSL  Functions  which  are  used  to  Initiate,  terminate,  and 
maintain  the  library  are: 


a . 

INITIAL 

Initialize 

a  project 

b. 

CREATE 

Create  or 

change  a  section 

c . 

TERMINATE  - 

Terminate 

a  section  or  sections 

d. 

BACKUP 

Backup 

e  . 

RESTORE 

Restore 

The  listings  from  the  runs  which  perform  these  Functions  for 
a  library  are  stored  In  the  Library  Maintenance  Archives. 

3 . 6 . 2 . 2  Execution  Archives 

Under  the  PSL  system,  a  test  run  is  performed  with  the  EXECUTE 
Function.  Additional  control  card  information  may  also  be 
added  with  the  JCL  Function.  The  entire  listing  from  a  test 
run  is  filed  unburst  in  an  Execution  Archives  box.  A  box  Is 
maintained  for  each  program.  The  boxes  are  arranged  on 
shelves  In  alphabetical  order  by  JOB  unit  name.  The  Functions 
which  produce  output  for  Execution  Archives  are: 


a . 

EXECUTE 

b. 

JCL 
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APPENDIX  A. 


STRUCTURE  OF  A  SECTION 


A  section  In  a  library  under  the  PSL  system  Is  created  In  the 
format  of  a  PSL  Standard  File.  The  organization  of  a  section 
is  shown  In  Figure  A-01.  The  structure  of  the  PSL  Standard 
File  Is  described  below. 

PSL  Standard  File  Format 


The  PSL  Standard  File  is  a  COBOL  random  (relative  access)  file. 
The  file  contains  128-word  blocks  (768  6-bit  characters).  A 
Standard  PSL  File  will  be  created  for  each  section,  except 
PROGRAM,  when  the  CREATE  Function  is  invoked  for  the  section. 

For  a  PROGRAM  section  the  CREATE  Function  catalogs  a  program 
file  for  the  storing  of  relocatable  and  absolute  elements. 

The  actual  name  of  a  section  file  is  a  concatenation  of  a 
one-character  section  code  and  the  name  of  the  user's  library. 
Thus  each  section  within  each  library,  under  a  given  project, 
is  represented  by  a  PSL  Standard  File.  Figure  A-02  lists  the 
one  character  codes  for  each  section. 

The  first  block  in  a  PSL  Standard  File  is  the  first  Control 
Block  for  the  file.  It  contains  information  pertinent  to  the 
entire  section,  such  as  section  name,  user-selected  options, 
file  size,  and  the  block  flags  which  are  used  to  control  the 
space  allotment  within  the  file.  The  first  Control  Block  also 
contains  the  block  number  of  the  first  Index  Block  for  the  file. 

The  Index  Blocks  contain  entries  pointing  to  the  locating  of 
each  data  unit  within  the  section.  Initially,  only  one  block 
is  assigned  to  the  index.  When  that  block  is  full,  another 
Index  Block  is  developed  and  half  of  the  entries  from  the  first 
block  are  moved  to  the  new  block.  In  this  way,  a  multi-level 
index  is  built  as  new  data  units  are  added. 
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Figure  A-01.  Organization  of  a  PSL  Section 
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Section  Name 
JOB 
LINK 
LOAD 
OBJECT 
PDL 

SOURCE 

TEST 

TEXT 

MGMT 

USER 

PROGRAM 


Section  Code 
J 
L 
X 
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M 
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z 


.  1 
'  I 

Figure  A-02.  Section  Codes  | 
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A  data  unit  within  a  section  may  be  stored  in  blocks  within 
the  PSL  Standard  File  or  in  a  completely  separate  sequential 
file,  referred  to  as  an  independent  file.  The  section  type 
and  unit  type  determine  which  format  is  used  for  any  given 
unit.  Structured  SOURCE,  unstructured  source  code  processed 
by  the  General  Preprocessor  (see  Appendix  I),  PDL  units  and 
straightforward  card  image  data  are  usually  stored  in  blocks 
within  the  PSL  Standard  File.  Unstructured  SOURCE  units  are 
stored  in  independent  files  and  must  have  unique  names  in  the 
project.  OBJECT  and  LOAD  units  are  Indexed  and  kept  track  of 
in  the  OBJECT  and  LOAD  sections  but  the  relocatable  and 
absolute  modules  are  stored  in  the  PROGRAM  section  with 
element  names  equal  to  the  unit  names. 
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APPENDIX  B.  SAMPLE  INPUT 


The  following  pages  of  Appendix  B  contain  sample  input 
which  illustrates  the  use  of  the  PSL  Functions. 


( 


0/0  AH  P  R  0  J  F  CT  r  F  H  A  f  P  3  A  R 
JPJTI/l  PR  0  JF  C  7  -f  HAC01  a  9 

iMim  re pjrr t;f Hiroi «  7 

P/RAM  PROJECT oF HA C01A7.L 1 BR AR YrPR OVF N 

C  n  r  A  T  C  SFCT^PRPG  ,rKSr <10«100> 

7  of  ATE  SF  r T2  0N -SOUR CF tf PMfRFSSrrrS.FHS  =  H 

!  *1  r  F  « 

r-'FATr  SECTIOK'-OBjrrT  .FMSrl 
]  Nr  FX 

f  r  f  A  TF  SFCTION=HGHT  *  F  PS.  ol  f 
J  V !  F  V 

f  =>F  ATF  RE  FT  ION- L  T '•«,  F  MS.  :1,  STANDARD:  YES 
ir>rrx 

t  r  A  TF  SF  CT  1 0  N  =  JOB  *  F  F*  S  :  1 
IMf  FX 

FRF  ATF  SECT IPNrTCST,FPr:l 
1*1  FX 

o/  RAH  POOJFCTtFHArOIAO.L  IBR ARY  =  »!EU CODE 

C  f  FATE  SECT:PROG«rR$=f 10,1CO> 

/ or ATF  SECTION -SCURcr  *  COM PR  E  SS-YrS*FMS“f  * 

MGMTQA  TA:  Y7S  .r.PCHF.CK- YFS.SPLFNGThoro 

INDEX 

f  or  ATF  SECT  ICN'RGH  ,F  PS :£P  tCDHPRF  Sf. s Yr  S 

I  N  r  F  x 

C  c  f ATF  SECTION  =  PDL*CCHPRFSS=YFr  *  F  Hc  =  1 

I I  T  x 

f  R  F  ATF  SFCTIO/'rTFxT.CPKPRirSiY'SfFMSrJ 


’  E  X 

f'FATF  SFCTION=OPjECT»PASSWPRr=MAGIC*FMS=l 

I  Nr  C  X 


I 


2 

PARAM  PR0JECI-FHACPH9 

PAR  AM  PROUCrTrFHACOlAT.l !RRARr=PR0VFN.SFr7]0N=S0URCC 

•  f'O  UNI TrT  TP  TPR.L ANGUACCrSCOBOL .PGMRrPFRT 

JirNUF  ICATION  DIVISION. 

F  ROGRAM- TO.  T  IP  TOP  . 

lNCLU^r  TlrTOP-rNVIRPNMfNT-Dl VISION. 

0  A  I A  DIVISION. 

lNFluOl  TIPTOP-F1LF-SCOTTON. 

INfLUDr  TIPTOP-WORK INF-STORAGT . 

PROOfOURF  DIVISION. 

INFLUOr  TIPTOP- PR  PC EDUPr -DIVISION. 

»FO  UMT-I IPTOP-FNVIRONMrNT-OlVISIONtPGMRiFERT 

rNVlRON-rNT  DIVISION. 

C  ONF  I  (.UR 4  T  I C N  SCO  T  I  ON  • 

SOURFC -COMPUTER  . 

UN  !  V  4  C  - 1  IT'. 

PPJFCT-CONPUTER. 

UN]  VAC-1  If)*'. 

•  srtcm  -NAMES. 

.  PROOFS  all  DEBUG  STATEMENTS. 


I NPUl -OUT PUT  SECTION. 

F  UE-CONTROL. 

S'UCT  IM'UT-rAROS 

ASSIGN  IP  CARO-READtP  CC. 

SU.ECT  MfSFAcr-FlLr 

ASSIGN  TO  PRINTER  MS. 

I -O-TONTPOL  . 

APPLT  r»rfF  ON  INPUT-CARDS. 
Pr''SArt-f  HE. 

IDO  UNlT-TIETPc'-FJLr-SFCTION*PGNR-BERT 
EILF  StTTION. 


F”  INPUT -CAROS 

LADFL  RECORDS  ARC  OMITTED. 

PI  INPUT-CARD  PIC  X«f>0». 
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ft  MFGSAGt-F  lie 

LtFFl  PCPPRPS  ARC  PHITTCP. 

"1  PEGS  f  GC-L  INF  PIC  XU20). 


••  AOP  SCn!ON  =  LINK,l'MlTrUPTOP,PFHR:rHARLES 
IN'  L  U'  f  T  I'  T  PP 
1 N '  LUTf  AOUNf 
IV'l'IPf  CMCC 
I.VlUPf  I T  r  j 
IN'LUOl  OPFN 
in-  nj^r  ppit. 

I  N  '  L  U  (.  F  PR  VT. 

IVlUOt  PF-RW 
IN' l  UP F  PP'P 
INCLUPf  FPUN 
INFLUOE  **  l  A  f 

••  App  rr  CT  lP'.'UPP  ,UN  ITrTIPTOP,UTvpFrINOEP.PGMRsCH*RLCSt 

•  •  F“'  :1 

<SG,fP  vr*F///100 

' A  f G. A  vr,  ,(  III  100 
-*  «  '  P  .  T  JP,F///KO 
'  A  <  r.  ,  T  UC.F///100 
••  as r. ,  fp  ui»F///ino 


trr..  a 

UL<F///]00 

p  A  £  fi ,  T 

PC.F///1P0 

■  a  r  ~ .  t 

p«,f///ido 

•  a  ;  r. ,  r 

FC.F///100 

•  c  r. .  T 

«f///ioc 

t '  1. .  T 

UT.F///1C0 

-  A  FI  •  T 

F  J  ,  p  /  /  /  i  0  0 

iA'-  r  ,  T 

FS,F///100 

■  t.  p  r, .  T 

TF.F///100 

F  M  r. »  T 

CHf  .F///10 

XF.F///100 

■  a  s  r.  • T 

XI.F///JOO 

'IFF:;  J 

fif  |F///1P0 

t  AEG.  T 

CF.F///100 

«A?0.T 

PT.F///100 

FASG.T 

XA.F///100 

GASG.T 

F1,F///I00 

?A  SG,  T 

F2.F///100 

PASG.T 

F3.F///300 

?  A  3  G  ,  T 

R0.F///100 

rasg,t 

R1  .F///100 

PA5C»  T 

R2.F///100 

FACG.T 

R3.F///100 

CASG.T 

RA1F///IOO 

f DATA  t 

I  CC.».  PSL 

pfno  pSL 

AXOT 

•  «  PAPAH  PRPjrrT=rHAC01A9,UBRAPY=NCUC0nEtSrCTI0»US0URCE 

••  ADD  UNMrTIPTOP-FRPCCDURf-niVISION.UTYPEsINCL.PCMRiCHARLCS* 

•  •  lANDl'ACEsSCOHOL 

P  A  TC  M  -P  31  -COMPPl. 

l  o i r. i  l a v  «  trait  -  ecu  icatch-ppl-contiiou  rurcuTCD*** 


•  «  PAPAN  PROjrFhACOlAO, LIBRARY: NEWC 00 E.SECTI  OA':PDL  *P6HR  :BERT 
••  *00  U«rT=TIPTOP-POl 

•  THf  MODULE  TIPTOP  PROCESSES  THE  RED  A  UNIT  FUNCTION  CADUNI 
TfPTOP 

IN1TIMJ7E  PARAMETER-! ABUT  WITH  SPACES 
CALL  •.'RU'* 

MCVr  PGMR-NAHr  TO  P AR* PET E R -TABLE 
OPEN  INPUT  INPUT -CAROS* 

OUTPUT  HE  SSAGE -F  ILE 
MOVE  »A00*  TO  INPUT-FUNCTION 
READ  IF PUT -CAROS 
It  NOT  £N0  OF  INPUT  CAPOS 
CALL  ’03FN* 

PO  UNTIL  NOPHAL  RETURN  FROM  OBFN 
f f ' P C H  PSL-EUNCTIONS 

WHIN  PSL-FUNCTION  IN  THE  TABLE  EQUAL  INPUT -FUNCTION 
SET  FUNO t ION-NUMBER  TO  INDEX  OF  T ABLE  • 

INCLUDE  PPOCCSS-FUNC TION. 

CALL 

ENOOO. 

CALL  PRINT  xrSSAGC  TEND  OF  INPUT  CAROS). 

IF  SP/UN  JO?  NEEDED 
INCLUDE  SPAWN-A-JOP 
TNDIF. 

ELSE 

CALL  PRINT  MESSAGE  ( NO  INPUT  CAROS) 

END1E . 

CALL  rLAF. 

CLOSE  INPUT-C*RDS« 

Mf-fMer-mt. 

Stop  RON. 

.*  PARAH  FROJ:FHA,'DlBB»LIBRARYsNEWC  OOT  .  SECT  I  ON*TE  X  T.  PtMR  "C  HARLE  S 
.»  A 00  UNTT  =  TIPTOP-TCXT 


TH‘  MOOULE  TIPTOP  PROCESSES  THr  PSL  FUNCTION. ADO  A  UNIT  < A DUN I 
NrW  UNITS  ARE  ADDED  TO  A  SPECIFIEO  PSL  LIBRARY  OR  CODE  ADDED  TO 
STUP  UNITS. 

A  LISTING  OF  THE  ADDED  UNIT  IS  PROVIDED. 


•  INDEX  PPr.JFCT  =  FHACDl*7.L  JRRARYsPROVEN.SEnRSOURCE 

•  l'TfX  PROJECT  :F  H  ACO 1 A  ° .L  T8RAPY:NEWC00E  *  CT  : SOURCE 

•  PAPA*  PR OJEC’iFHACOlAR. LIBRARY: Nr WC 00 E 

.  DOCUMENT  LSPACt , P A CE :0 . SECT  I  Of =TEXT 

•  HEADER  HSPACE:.' 

T  'PTOP-TCXT-HEAOER 

•  TEXT  Uf  IT  - T IP TuP- T I  XT 

•  OCCUMrNT  PAE,E:1  ,SECTION=POL 
.  HT  AOT  R  HSPACE  :1  C' 

r  ir  rnr-roL  -nr  tnrp 

•  TEXT  UNJTrT JPTOP-POl 
i'fjC  CT 

•  T(  vt 

TUTS  frxT  SHOULO  PE  AT  THF  TOP  OF  THE  PAGE. 


\ 


it, 


\ 

t 


■i 


••  P  A  R  AM  PR0UCCT:FHACD1A9  - 

..  P*P  AM  PR0UECT=FHACD1  A7,LlBSARY:P#0VfN.SECTI0N  =  MGMT 

••  Mr  FORMAT  LCVEl:SYSTCH,OP =AD0 

lOJO  l?PROJ-riTL‘  PROJECT  TTTtf 

!  r-  2  C  «PT  4FPRPJ-D7  SCP  pPOJtfT  DfSCRIPTION 

7C10  MCFSTART-OA Tr  PROJECT  START  OATE 

10*0  N06f,'T-r\P-0,Tr  ESTIMATED  COMPLETION  DATE 

1050  NrSACT-ENC-OATt  ACTUAL  COMPLETION  OA  Tf 

fiCO  Nfi'P-AVE-wr.PS  PL  ANNE  0  AVERAGE  ''EARS  EXPIRTENCE  MANAGERS 

IE7n  N03P-AVE-ANAI  PLANNED  AVERAGE  YEARS  EXPERIENCE  ANALYSTS 

IffO  N03P-A  Vr-FROf.  Pt  ANNE  O  AVERAGE  YEARS  EXPERIENCE  PROGRAMMERS 

I E  90  NO.’P-AVE-ADM!  N  PLANNED  AViPAGC  YEARS  EXPERIENCE  ADMINISTRATIVE 

II  CD  N02P-A  VE  -OTH  PLANNED  AVERAGE  YEARS  EXPERIENCE  OTHER 

T,10  NO  3A-AVF -VGR<-  ACTUAL  A  VFR  A  G  r  YE  A°S  rXPEPIFNCE  MANAGCRS 

1120  NO  3A-AVE-ANAI.  ACTUAL  A  Vr  R  AG  E  YEARS  EXPERIENCE  ANALYSTS  « 

1130  N03A-AVE-! ROG  ACTUAL  AVERAGE  YEARS  EXPERIENCE  PROGRAMMERS  / 

1140  NCSA-AVF-ADMTN  ACTUAL  AVERAGE  YEARS  EXPERIENCE  ADMINISTRATIVE  -i 

1150  N03A-AVE-OTH  ACTUAL  AVERAGE  Yf arc  rXPEPlENCE  OTHER  i 

neo  ncap-npr-mgrs  planned  njmpfp  of  managers 

7:70  noap-a «r-anal  planned  number  of  analysts 

T’PO  NPAP-NPR-PROG  PLANNEO  NUMBER  OF  PROGRAMMERS 

I’c0  N04P-NSR-ADM1N  PLANNEO  N  I’MP  f  R  OF  ADMINISTRATIVE 

1200  NOAP-NcP-CTH  PLANNED  NUMREP  OF  OTHFR 

1 2 1 C  NOAA-NRR-vfiRS  ACTUAL  NUMPFR  OF  MANAGCRS 

1220  NC4 A-NRR-ANAL  ACTUAL  NUMPFR  OF  ANALYSTS 

1230  NOAA-NBR-oROG  ACTUAL  NUMBEP  OF  PROGRAMMERS 

7  7  AO  NOAA-NBR-AOMTN  ACTUAL  NUMPFR  OF  AOM I N 1ST R A TI Vr 

1250  NOAA-NRR-sTH  ACTUAL  NUMPFR  OF  OTHER 

TOGO  NOTE-TUR'OVER  E'TIMATEO  PERSONNEL  TURNPVCR  RATE 

1770  NO  3A-TUP  NO VE  R  ACTUAL  PS  RSONNEL  TURNOVER  RATC 

I7F0  N03E-LCC-TR1PS  ESTIMATED  LOCAL  TRAVFL 

:790  NOTa-LOC-TRIPS  ACTUAL  LOCAL  TRAVEL  '* '  * 

'300  NtTr-niS-TRlPS  ESTIMATEC  DISTANT  TRAVEL 

'110  N0.3A-DI5-TRIPS  ACTUAL  DISTANT  TSAVFl 

i -an  fcPif*wnPA=eef!3  [STWTffl  wopkjne.  conditions 

1130  NOIA-WGRk-CDND  ACTUAL  WORKING  CONDITIONS 

l’AC  N07P-LANG-EXP  Pt.  A  NNTO  PROGRAMMING  LANGUAGE  EXPERIENCE 

T 1 50  N02I-LANG-EXO  ACTUAL  PROGRAMMING  L A  NGUA  GE  EXPERIENCE 

T’fcO  N02P-SIM-CXP  PLANNED  SIMILAR  APPLICATION  EXPERIENCE 

1370  N02A-S1M-' XQ  ACTUAL  SIMILAR  APPLICATION  EXPERIENCE 

i’ro  Noip-TARc.-rxp  planned  target  computtr  experience 

1290  NOPA-TARG-f  YP  ACTUAL  TARGET  COKPUTCR  FX  PER  1 ENCT 

7  A  00  N02E-APPL-EXP  EST7MATEP  CUSTOMER  APPLICATION  EXPERIENCE 

I  A  1 C  N02A-APPL-EXP  ACTUAL  CUSTOMER  APPLICATION  EXPERIENCE 

1A2<1  NOPE  -r'HUR-rxP  ESTIMATE."  CUSTOMER  EQUIPMENT  EXPERIENCE 

I A  30  NOPA-EGUIP-EXP  ACTUAL  CUSTOMER  EQUIPMENT  EXPERIENCE 

I A  A  0  NOIC-rOMPLEXITY  ESTMATED  COMPLEXITY  OF  PROJECT 

1*50  N31A-C0MPLEX1 TY  ACTUAL  COMPLEXITY  OF  PROJECT 

iRfeC  NOAEOf C-FUNC-'P  ESTMATED  PAGT?  DOCUMENT  AT  I  ON  FUNCTIONAL  SPECS 
1*70  NCAf POC-tlsrfi-AU  rSTMAlEO  PAGES  0OCUMFNTATJ0N  USERS  GUIDE 

IARO  NOAEDOC-TEST-FP  ESTMATED  RAGES  DOCUMENTATION  TEST  SPECIFICATIONS 

1*Q0  NOAf DOC-Pf OG-LT  ESTIMATED  PAG!"  DOCUMENTATION  PROGRAM  LISTING, S 
rno  NOAAI rr-EUNC-'P  ACTUAL  PAGES  DOCUMENTATION  functional  sprcs 

I*  10  NOAAOCC-U' ER-GU  ACTUAL  PAGES  OOfuMf NT  A  II  ON  USERS  GUIDE 
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**** MUntirfhm&mt-. 


I 


PAPAM  PR0JECT=FMAC014r. LIPPARYrNrUCOOF 

M" FORMA  T  LFVFLrSYSTFMt0P=M0VF#PLCP=FHACD147*0LDLPPR0VrN 
Mr  F  OPH  A  T  LTVf  L^SO0*;  YSTFM.  OP:  MO  Vr  .OLDPrFH  ACPI  4  7.  OLOL -PROVEN 
Mr  FORMA  T  L  F  Vf  L  =  MOPULf  ,  PP  =  MOV  F  *  r>L  OP  =  FH  A  CD147tOLI'L  =  PROVFi'J 
Mil  F  OR  M  a  T  LFVCL-JOR.OPrMOVE,OLnr-FMAC0147,OLOL-»POVrN 
M- FORMAT  LrVFLrUNII,OP-MCVF,OLnP-FHACni47,OLOl=PROVFN 
MOPLAN  MOO  =  0 

INSERT  AFTFRrfl 

EYSTfMrNEUConr ,L  »B?rpRnVFN.L IR J- JOHN. 

PF0JPrFH,r014  7*PFOJ3=FHACDl 4  0 

supsYFr  Nf  wconr-PM 
m  on  i/l  F  ;  T  I  F  TOP 
MODULE =  AOUME 

SUR?Y'-rNf  WCODE-CU 
JOP :T ] PTOP-CU 
jr<-  =  AnCN-C  U 

PA  PAM  PROJECT  =  FHAC014  7,LIBPARY=PROVCN 
MDUPOATE  UNITrOROVE N.lf VC L  =  S YSTFM, CP  =  A  DO 
J-pPOVFN-TITLr 

0  =°R  0 VF  N  TEST  PROJECT  OFSCRIPTION 
0  =  7  70 1 0  1 
0=77080 1 
0  =:7  70  810 
0  =  008 


T 

.1, 


■Jj'**.**  .<* i  ‘a  4  Vi  if  iSjAM,.*-.  j»  a 


TF RMINATE  PR  OJECTiFHAC01*9.1IBRARY::MARY.  SECT’ ON -SOURCE 

CREATE  F»F:J 

ADD  UN'T-INTrRPRCT-KEYWOPD-VALUES.UTYPr=lNCL,KEYrHYSTERY. 

LAN&rMOBOL 

INTtPPRFT-KEYUORO-VALUFS. 

3  O’SPLAY  •  TRACf  -  A  Dl'N  < T NT T R P Rf T -F C YWPPD- VALUE S >  EXECUTED.*. 
CiSENTi  T  KF-YUCRD-NPR 
CAM  ? 

IF  Lf  NG  Th-PF  -  VALUE  GREATER  Than  LEE  GTH-nr-KEY-VALUP 
K<w  c  or  r -eor-vaiuf  -  trcor  tp  peturn-copc 
FL  E 

MOV  KEYPORD-VALUE  TC  I NP JT -UN  I T -HE Y 
ENME 
C  ft  ' 

IF  LCNf  TH-np-VALUE  GREATER  THAN  LE  NGTH-OE -LANGUAGE -NAME 
*OV  CPPE-ECfi-VAl  ur-ERRPR  T"  RETURN-CODE 
ELM 

»*0 V *  KE  YLTRO-VALtlf  TP  INPUT-UNIT-LANGUAGE 
END  IE 
CAM* 

MOVE  RPACPf  TO  LIFiPAPY-NAME  OE  P  AP  (  ME  T  E  P -T  ABL  F 
IE  LENGTh-PF-VALUE  GREATER  THAN  Lt NG TH-CF - L IBRARY-NAHE 
ROVE  COPE-EOR-VALUf -ERROR  TO  RETURN-CODE 
f  LM 

MOV  KT  Y  WORD  -  V  A  LUE  TP 

L  !:‘RARY-NAME  OF  P  A  R  AME  T  EP- T  A  BL  E 

ENDiE 
E  NOC  A  c  E 

INTERPRET -KEYWPRO-VALUES. 

EXIT. 

CHANGE  UNITMNTERPRET-KF  Y WORD-VALUES .KEYpMYSTERY 

SHIFT  lINErl.COLU-LA 
MODIFY  UFESPtS.p) 

MOVE  ".PACE  TO  SECTION-CODE  OF  P  A»  A  MTTr  R -T  AB  LE 
IE  LENGTh-PF-VALUE  G»EAtER  THAN  LTNOTM-OF-SCCTION-NAMC 
move*  CODE -FOP-VALUE.-rRROR  TP  RCT URN"C0DF 
LLrt 

MOV  KrYMERO-VAlUE  TP  I  NPtlT-S  fCT  1 ON-NA  MF 
SET  ST-IMOrx  TO  T 
CE  ARCH  SECTION-TABLC-i  NTRirr 
AT  r»D 

MOVE  COlE-FOR-VALUE-CPROR  TO  RETURN-COOE 
WHEN  SEC (ION-TABLE- NAME  • ST- I NDE  X ) 

EOUAL  TO  INPUT-SEETION-NAME 
MOVE  SECTION-TAELE-NAME-COPE  CST-INOFX) 

TO  MCTION-CODE  OF  PARAMETER-TABLE. 

E  AID  I  F 

OE  LE  IE  LIJES-FIO.I'  > 

MODIFY  LpIG.FROMtCA  sr«.  TOp'CAST 
INSERT  A  c  TE  R  - ’ 

CAFE  S 

IF  Lf UGTH-Pf-VALUE  GREATER  THAN  IE NGT H-or -P ASSUORD 
MOvr  SFAEES  TO  FAS'WORP  OF  PA RAMT TFR-TABIE 
MOVE  CODE -FOR-VALUF -ERROR  TO  RET  UKN-L  ODE 
TIM 

MQV  KE  YWORO-VALUE  TO  PASSWORD  OF  PA RA ME TE R- TAB LE . 

FNFJIF 

COPY  AFTE»:JA.OLOUNITrjf)UN-PROrE  >UP1  -DIVISION, 0101=  JOHN, 

F  POM  r  16 

SHIFT  L  INF  - 2 r  .roi  l':«* 

mo  >irr  UYrerri.cmiOMos-mi. 
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..  PARAM  PROJt CTrFHAC01«7,LIBRAPY-PROVFN»SCCTION=SOURCE 

•  •  CSCAN  SIR  I  NO  :T I PT  OP 

•*  PAPAM  FR"JE CT:FMAC01A9.L!»RARY:J0HN,EECT !ON:LOAO 

••  CRfATf  FM'.rl 

>*  LINK  l 1NK:T IPTOP,LIFJ-N!  WCOOE ,L IP  Jr PROVF N.PR 0 JJrFHACOl* 7 

•*  EXECUTE  JOF  =  7IP70P«PROJ2-FhaFD147*L1BF'-PPOVEN 

..  IN"£x 

♦*  PtRAM  PR0JfCT:CHAC01A7,L18RARYrPR0VrN,SECT10N=MGMT 

•*  mqplAN  mod  =  o 

•  •  INSERT  AFTER-" 

SYSTEM: PR OVEN.LINl^PROVfN 
suasrc-suRTnp 

MODULES  IPT  OP  ,L  IROrNEWCODE  .  PRO  JO=F  MAC  01  *»9 
MODULE  “AOUN/  t  L  TP  3- JOHN 
JOPrTIPTOP-CU 
JOfjrAOU*l-CU 

•  *  param  project rf haoci a r,lirrary -newfode 

•  •  Mr  FORMA  T  irvrLrSYSTCM.OPPCHANGr 

R  280  NC3E-LOC-TRIPCH  ESTIMATED  LOCL  TRAVEL  CHANGE 

R*  50  NOIA-COMFlE»-CH  ACTUAL  COMPLEXITY  OF  PROJECT  CHANGE 

0710 

1P30M210TTLLIE  ES-EOP'EO  LINES  OF  SOURCE  CODE  COPITO 
1PA0M220TTLREAL-UNIT-CT  REAL  UNIT  COUNT 
1R50M2JOTTLSTUP-UMT-CT  STUB  UNIT  COUNT 
JBfcC  NOANRR-l  IriES-PL  NUMPER  OF  SOURCE  LINES  PLANNED 
R 5A0  2XSY0-NA MERFL  SYSTEM  NAMT  EDIT  NPR  REPLACED 

Pr50  2ASUrSY"-NAME  SUBSYSTEM  NAME  EDIT  N»R  R  t  PL  ACDE 

••  MPUPOATE  IJNI'=NEWCOOE*PN*OP  =  CHANGE 
••  INSERT 
260:0001 COOO 
»•  MC 0 1 F  V 
170:0075 
250:00001025 
•«  DELETE 
290 

»•  H'TCHfCK  UNITsAjlKCPOC 

••  INSERT 

210>160:V01«051177«MOPr  MGRS  THAN  PLANNFD 
?90>280:V10, 051177, MORE  LOC  TRIPS  TMAN  EST 
7C0>G9C:V50, 051277, TCO  FTM  SUCCESSFUL  RUNS 
7JO<B60:V10. 053077, TOO  LITTLE  SOURCE  CODE 
..  PACAM  FROJECV=FHAC01A7, library-proven 

«•  Mn  X  C  hE  C  K  UNITrrRO'iEN 
••  INSERT 

A50SA40: V15,Cf 1 177, COMPLEXITY  OVFR  EST 
C50M1A0: VPO.051 I’T, COMPLETION  DATE  NOT 
?30>180:V01, 051377, TOO  MANY  PROGRAMMERS 

•  *  MCXCmECK  UNI 7:PR0VE  N 
•*  MODIFY 

A50<4«0:750. 051777, COMPLEXITY  OVER  EST 
»•  T  NC  E  y 

•  •  index  PROjrcT:FHAcniAP,i  iPPARr--Nruroo r  .  . 

••  PARAM  PRO JECT:FHAC01*9, LIBRARY- NEUC OOE 

••  MOCOLLECT 

,«  Mi. PRINT  RETORT  :HO 

•  •  PAR  AM  PR0JECT:FHAC01«7,L IBRARY-PROvrN 
••  MOCOLLECT 

.»  MRPRINT  RTPORT-MO 
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»  SOURCE  LtPR-JCMN.  ftT:rnu»rr. 

•  UNI T'»OUN-PRO»rrur r-Tl VISION. INDENT -NO  ' 

•  AUTHOR  L  If  RrNELCPOc  .l>r f  **0 ' r hA "  l£  r  ,r  PG**R  =Crt(  »lc  *■ 

•  AUTHOR  C  If-R  rDoout'N  .UPGMP  iHfp  T.PRO  J-FHACOH  '  »  OP MR  r  R  r  R  ’ 

»  AUTHOR  LIBpR  JOhN.URGHP  rjl  NDY  .PRCiJrF  HAC01<tr- ,  OPGA  RrWENOY 

•  compile  uni  t  rj^t/r  .pro  jec t  ~e  hacei  rs ,l  ’ r  i=ucmn,l  16 ?-newcooe » 

•  OBJECT-YES 

•  ‘‘YECUTE  JOr  -  T  1  P  TOO  ,  L  INK -T  IP  TOP  ,OPOJ1  rf  HAC3  1  A9, 

•  Lini^jOHN.L IRPiNEWOOPr . 

•  PRPUJrfHACDlAT, LIP’S-"  90VI*! 


RESTORE  PRCJpEhaCDIRN.LIBRp JOHN, UN  I T R ADUN-PP OCE D UR E -  0  I V  I S I  ON, 

SECTION-SOURCE 

PA°AM  PR0JpEHACOl«S,f F CTrSCURCf 

REPLACE  UNIT: S TORE-1 NPUT-xrTwCROr»Ll BP APYr JOHN 

HOVE  SPACE  TO  SECT;  ON-EO:'E  Of  P AP A MCT t 0 -T ABLE 
!c  LENT TH-PF-VALUE  GREATER  THAN  LE NGTH - OE - SEC T ION-NAME 
HOVE  COPE -EOP-VALUE-ERROR  TO  return-code 

ELSE 

HOVE  KEYVORO-VALUC  TO  ] NPU T -SE C T I  ON- N AHr 
'ET  ST-1NOCX  TO  1 
EEARCH  SECTION-TABLE-ENTPirS 
AT  FAQ 

BOVE  COOf-EOR-l'ALur-rRROR  TO  RETURN-CODE 
WHEN  SECTION-TABLE- NAME  <ST-INOET) 

ECU'L  To  INPUT -SECT  ION-NAME 
•'AOVE  EECTION-T/hle-NAHE-CODE  IST-TNDtX) 

TO  SECTION-Conr  of  parameter-table. 

ENOIF 

SOURCC  UNI  TrAOUN-PP  OCE  OURE-OI  V  IS  T  OM.NBRL  INF S : JO , 1 N 0t NT =NO 

source  unit=.ai  i 

PARAH  PROJECT=FHACD1AR,LIBRARYrNEWCODF. 

OOCUMENT  L SPAC t  =  J. P AGE  si i SECT  IONS  TEXT 
HEADER  MSPACEs*' 

TIPTOP  Ot  S  C°  TP  T ION 
TEXT  UNITrTJPT  OP-TEYT 
MOPLAN  SECTrMGHT.MODsj 
DELETE  L I N  E  R  r 
MDIOLLECT  ARCH1VERTES 

HprcLtrcT  archive ?  ye  s 
H.'PPINT  repcrt  =  hd 
Mf  F  P  I  NT  REPORTED. HIST-ALL 


TEPMINATE  PRQJFCTapmACO1A9.LIBPRJ0HN*SECT=ALL 
COE  ate  SEC  TrSOURCC , MGMTO A TAryFS . SPC ME CK* Y r S .SPLENG TH^SS, 

rx':' 


CREATE 
Cf  E  ATE 
»'  STORE 
r  A  RAM 
AOVr 

peplaceryee 

MOV' 

P  rPLACE  RYl S 
h  r  P  E INT 

compile 

DfPAM 

t  URGE 
cURGf 


SECT-OBJECT ,FHS=I 
SEETrLPAENFME.-I 
PPOJECTAEMACOIRRf L  IBPrAIL 

BRCJERTsFH.ACOI  Ro.LIPPAPYrNEWCOOE.SE  CTIONr  SOURCE 
UNI  Tof.DUN- CROCE  OURf  -D  1  V I  S I  ON, OLDL I E  PJOHN, 

UNI  TrAOUN-WCPK  ING-R  rr-R»r.F  -SECT  ION,  OLDL  IBs  JOHN, 

UN’TrAOUNF  .REPCRTsf’S 

UNIT:*  E»UNf  , CpT 1 ONS - Tl  ,P  A  SS  =MA  G  I  C  ,  Of  JE  C  T  SNO 
L  I !  P  AR  »  =  JOHN,  P  A  S S=  *  ’ 

U N  ’  T  --  AOUN-F  ROTE  OURC-C  1  V  I  SI  ON 
UNI  T  --A.SUN  -  WORN  1NG-E.TOR  'CT -SECT  ION 


1 1  f  t  * 
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APPENDIX  C.  MESSAGE  OUTPUT 


Messages  which  are  printed  by  the  PSL  system  are  divided  into 
the  following  categories: 

a.  Advisory  -  A  condition  exists  which  may  require 
user  attention. 

b.  Error  -  An  error  has  been  encountered  which  has 
prevented  normal  completion  of  the  processing. 

c.  FMS  -  The  Executive  System  has  returned  an  error 
status  code.  The  status  bit  number  (FMS-ERROR- 
NUMBER)  and  the  appropriate  error  message  (FMS-ERROR- 
MESSAGE)  is  printed  by  the  PSL  system.  A  subsequent 
mf ssage  will  give  further  information  as  to  the 
effect  of  the  error  on  the  processing.  For  further 
detail  of  error  messages,  see  Univac  11C0  Series 
Executive  System  Diagnostic  Messages  and  Status  Codes 
(Facility  Status  Bits  Table). 

d.  Information  -  These  messages  provide  status  infor¬ 
mation  to  the  user.  They  are  printed  during  normal 
processing . 

e.  MSG  -  General  messages  which  may  be  generated  during 
execution  of  a  PSL-spawned  job. 

f.  PSL  -  A  message  in  this  category  may  indicate  a 
problem  in  the  PSL  system.  If  such  a  condition 
should  arise,  the  user  should  contact  system  support 
per  sonne 1 . 

In  the  following  list,  the  messages  are  grouped  according  to 
category,  which  is  indicated  by  the  first  three  characters  of 
the  message  number. 
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ADV006  UNABLE  TO  ASSIGN  REQUESTED  FILE  WITH 
ACCESS-access-mode 
ALLOC AT  I ON -allocation-type 
PROJECT-project-name 
LIBRARY -library-name 
SECTION-section-name 
UNIT=unit-name 

ADV016  JOB  SPAWNED. 

ADV054  PREVIOUSLY  COLLECTED  ELEMENT  unit-name  IN  PLAN 
LINE  line-nbr 

ADV057  SUBORDINATE  ELEMENT  unit-name  NOT  PROCESSED  IN 

PLAN  LINE  line-nbr 

ADV058  UNABLE  TO  UPDATE  BEYOND  LAST  LINE  (las t-1 ine-nbr ) 
IN  UNIT 

AD V 0 7 0  REAL  UNIT  unit-name  NO  LONGER  INCLUDED  BY  ANY 

HIGHER-LEVEL  UNIT 

ADV 106  UNABLE  TO  MOVE  UNIT-unit-name  BECAUSE  REPLACE-NO 

AD V 1 3  3  UNABLE  TO  MOVE  STUBUN IT-un i t -name 

ADV 137  RESTORE  INITIATED  FOR 

PROJECT-project-name  LIBRARY -library -name 
SECT! ON -sect  ion-name 

ADV140  RESTORE  COMPLETED  FOR 

PROJECT-project-name  LI BRARY-1 ibrary-name 
SECTION-section-name 

AD 7 14 1  EXISTING  UNIT  DELETED  PRIOR  TO  RESTORE 
UNIT-unit-name 

ADV 142  UNIT  RESTORE  COMPLETED  FOR  UNIT-unit-name 

ADV150  UNABLE  TO  COPY  BEYOND  LINE  line-nbr  FOR  UNIT 
uni f  -name 

ADV160  STRING  REPLACED  repeat-nbr  TIMES  character-string 

ERR001  INVALID  FUNCTION  function-name 
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Msg  . 
Key 

ERR002 

ERR003 

ERR004 

ERR005 

ERR007 

ERR008 

ERR009 
ERR010 
ERR  0 1 1 

ERR013 

ERR015 

ERR017 

ERR019 

ERR023 

ERR026 

ERR030 

ERR032 

ERR035 


Message  Text 

INVALID  KEYWORD  Keyword 

ATTEMPTED  TO  ADD  UNIT  WHICH  ALREADY  EXISTS  unit-name 

UNIT  TYPE  OF  EXISTING  UNIT  unit-name  IS  unit-type. 
INCONSISTENT  WITH  REQUESTED  UNIT  TYPE. 

NO  SPACE  AVAILABLE  UNDER 

LIBRARY  library-name  SECTION  section-name 

UNABLE  TO  PROCESS  PREVIOUS  REQUESTED  FUNCTION 

ATTEMPTED  TO  CHANGE  STUB  OR  NON-EXISTENT  UNIT 
unit-name 

INVALID  UNIT  KEY  unit-key 

INVALID  SECT ION" sect ion-name  FOR  REQUESTED  FUNCTION 

INTERNAL  TABLE-table-name  EXCEEDED  DUE  TO  NUMBER 
OF  ITEMS.  MAX.  ENTRIES  number-of -max-items . 

SYNTAX  ERROR  IN  COLUMN  column-nbr 

Note:  Special  mark  indicates  column  in  error. 

NO  INPUT  CARDS  FOUND 

INVALID  PLAN  LINE  line-nbr 

KEYWORD  VALUE  ERROR  value 

UNABLE  TO  INITIALIZE  STANDARD  PSL  FILE 
PRO JECT-pr o j  ec  t-name  LIBRARY" library-name 
SECT ION"sect ion-name 

UNIT  unit-name  NOT  FOUND 

INVALID  DATA.  REJECTED  MGMT  UNIT  -  unit-name 
MISSING  REQUIRED  KEYWORD  keyword 

ERROR  ON  PARAM  CARD  (SKIPPING  TO  NEXT  PARAM  CARD) 
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Msg  . 
Key 

ERR036 

ERR053 

ERR055 

ERR056 

ERR059 

ERR060 

ERR061 

ERR062 

ERR063 

ERR064 

ERR065 

ERR066 

ERR068 

ERR069 

ERR071 

ERR075 

ERR076 


•aftW  ;  .it 


Message  Text 

SECTION  ALREADY  EXISTS  IN  LIBRARY 

LEVEL  INCONSISTENT  WITH  FIRST  OCCURANCE  OF  ELEMENT 
unit-name  REPEATED  ELEMENT  REJECTED. 

REJECTED  INCLUDE  STATEMENT  FOR  UNIT  unit-name 

MAXIMUM  NUMBER  OF  CHARACTER  (max-nbr)  EXCEEDED 
FOR  NAME  OF  UNIT  unit-name 

MAXIMUM  NUMBER  OF  CHANGES  PER  LINE  -  6.  LIMIT 
EXCEEDED  FOR  LINE  NUMBER  line-nbr.  FIRST  SIX 
CHANGES  APPLIED. 

UNACCEPTABLE  FMS  DIRECTIVE  fms-keyvord 

INVALID  FMS  PERMISSION  fma-entry 

MAXIMUM  NUMBER  OF  FMS  USER  NAMES  -  8.  LIMIT 
EXCEEDED.  EXCESS  IGNORED. 

INVALID  FMS  DEVICE  SPECIFIED  fms-value 

INVALID  REFERENCE  BY  level  FORMAT,  ITEM  item-nbr 
TO  level  FORMAT,  ITEM  item-nbr 

INVALID  XCHECK  REFERENCE  TO  ITEM  item-nbr  IN  MD-UNIT 
unit-name  XCHECK  SPECIFICATION  xcheck-spec. 

ERROR  WHILE  PRINTING  UNIT-unit-name 

INVALID  UNIT  TYPE  (unit-type) 

FOR  INCLUDED  UNIT  unit-name 

UNABLE  TO  PROCESS  FMS  FILE  OPTIONS 

MISSING  CONTINUATION  CARD 

UNABLE  TO  ACCESS 

PROJECT-proJect-name  LIBRARY-library-name 
SECTION-aect ion -name  UNIT-unit-name 

USER  DATA  REQUIRED 
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Msg . 
Key 

ERR081 

ERR082 

ERR083 

ERR084 

ERR085 

ERR088 

ERR09  2 

ERR097 

ERR098 

ERR100 

ERR102 

ERR103 

ERR10A 

ERR105 

ERR131 

ERR134 

ERR135 

ERR136 


Message  Text 

PROCEDURE  procedure-name  NOT  SUPPORTED 

INVALID  VALUE  FORMAT  FOR  KEYWORD  (keyword) 

INVALID  FLAGWORD  (f lagwor d-specif lcatlon) 

INVALID  ACCESS  CODE  (f lagword-speclf lcatlon) 

INDEPENDENT  FILE  INVALID  FOR  STANDARD  SECTION 
(section-name ) 

INDEPENDENT  SOURCE  UNIT  REQUIRED  FOR 
PROCEDURES  procedure-name 

ILLEGAL  UNIT  TYPE  FOR  COMPILE  FUNCTION  FOR 
UNIT-unit-name  UNIT  TYPE  unit-type 

INVALID  SECTION  PASSWORD  password 
PROJECT-pro j ect-name  LIBRARY-library-name 
SECT ION- sect ion -name  UNIT-unit-name 

USERID  DOES  NOT  MATCH  PROJECT 

INVALID  MODIFICATION 

UNIT  MODIFICATION  IS  CURRENTLY  modif-Level 

UNABLE  TO  MOVE  UNIT-unit-name  BECAUSE  OF  EXISTING 
UNIT-KEY 

ILLEGAL  MOVE.  SAME  LIBRARY  SPECIFIED. 

ILLEGAL  MOVE.  SAME  UNIT  SPECIFIED. 

UNABLE  TO  MOVE  UNIT-unit-name 
UNABLE  TO  BACKUP 

LIBRARY-library-name  SECTION-sect ion -name 

NO  BACKUP  UNITS  FOUND  TO  MEET  RESTORE  REQUIREMENTS 

THE  FOLLOWING  KEYWORD  IS  UNNECESSARY  AND  IN 
ERROR  keyword 

RESTORE  PROJECT  UNMATCHED  BY  BACKUP 
PROJECT-proj ect-name  LIBRARY-library-name 
SECTION-sect ion-name 
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ERR138  EXISTING  SECTION  TO  BE  RESTORED 

NOT  FREE  OF  UNITS 

PROJECT*pro j ect-name  LIBRARY* library-name 
SECT ION*sec t ion -name 

ERR143  UNIT  RESTORE  FAILED  FOR  UNIT-unit-name 

ERR144  BACKUP  END-OF-FILE  ENCOUNTERED  PREMATURELY 

ERR145  BACKUP  FILE  FORMAT  IN  ERROR 

ERR146  SECTION-HEADER  MISSING  ON  BACKUP  FILE 

ERR147  SECTION  RESTORE  FAILED  FOR 

PRO JECT*proJ  ect-name  LIBRARY ■library-name 
SECT ION* sect ion-name 

ERR148  MAXIMUM  NUMBER  OF  HEADER  LINES  (max . -header-line 
count)  EXCEEDED 

ERR152  UNABLE  TO  OBTAIN  FMS  PARAMETERS  FOR  INDEP-UNIT 
PROJECT-proj ect-name  LIBRARY*library-name 
SECTION* sect ion-name  UNIT*unit-name 

ERR153  UNABLE  TO  BACKUP  UNIT  unit-name 

LIBRARY* library-name  SECT ION*sect ion-name 

ERR155  OPGMR  DOES  NOT  MATCH  UPGMR 

ERR158  RESERVED  UNIT  NAME  SPECIFIED 

ERR161  INVALID  OP-CODE  FOR  RECORD  data-record 

ERR190  FORMAT  ERROR  edit-pointers 

ERR193  ITEM  NOT  DESCRIBED  IN  APPROPRIATE  FORMAT  UNIT 
ERR194  ITEM  IS  NOT  MANUAL  DATA 

ERR195  ILLEGAL  SPECIFICATION  FOR  XCHECK 

ERR196  INVALID  DATE  FOR  XCHECK 

FMS200  FMS  ERROR  NUMBER  f ms-err or-nbr  f ms-error-message 
PROJECT*pro j ect-name  LIBRARY*library-name 
SECTION*sect ion-name  UNIT-unit-name 
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Mag . 

Key 

INFO 14 
INF099 

INF 10 1 
MSG  76 

MSG  77 

MSG  78 

MSG  79 

MSG  80 

MSG  83 

MSG  84 

MSG  85 

MSG  111 


Message  Text 


END  OF  INPUT  CARDS 

LIBRARY- library-name  SECTION-sect ion -name 
WRITTEN  TO  BACKUP-FILE 

LIBRARY-llbrary-name  SECTION-section-name  TERMINATED 

UNIT  hlgher-unlt-name  LINE  llne-nbr 
ERROR  WHILE  READING  UNIT 

PRO JECT-pro j ec t-name  LIBRARY-llbrary-name 
SECT ION-sec tlon -name  UN IT-unit -in-error 

UNIT  higher-unit-name  LINE  llne-nbr 
UNIT  NOT  FOUND  IN  LIBRARIES 
UNIT-unit-in-error 

UNIT  hlgher-unlt-name  LINE  llne-nbr 
INVALID  UNIT  TYPE  FOR  INCLUDE 
PROJECT-pro jec t-name  LIBRARY-llbrary-name 
SECTION-sectlon-name  UNIT-unit-in-error 

UNIT  higher-unit-name 

INCLUDED  UNITS  ARE  NESTED  IN  RECURSIVE  LOOP. 
PROJECT-pro j ect-name  LIBRARY-llbrary-name 
SECTION-section-name  UNIT-unit-in-error 

UNIT  hlgher-unlt-name  LINE  llne-nbr 
INCLUDED  UNITS  ARE  NESTED  BEYOND 
LIMIT  OF  50  LEVELS 

PROJECT-pro  j  ect-naije  LIBRARY-llbrary-name 
SECTION-section-name  UNIT-unit-in-error 

UNIT  link-unit-name 
REQUESTED  LINK  UNIT  NOT  FOUND 

UNIT  object-unit-name 

ERROR  IN  FORMAT  OF  OBJECT  MODULE 

UNIT  object-unit-name  ^ 

SKELETON  FOR  OBJECT  STU1  MOT  FOUND 

UNIT  unit-name  LINE  llne-nbr 

CASE  ENTRY  STATEMENT  MISSING  NUMERIC  IDENTIFIER. 
ERRONEOUS  CODE  MAY  RESULT. 
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MSG  112  unit  unit-name  LINE  llne-nbr 

DO  STATEMENT  MISSING  WHILE  OR  UNTIL.  WHILE  ASSUMED. 

MSG  113  UNIT  unit-name  LINE  line-nbr 
CASE  FIGURE  HAS  NO  CASE. 

MSG  114  UNIT  unit-name  LINE  line-nbr 

EXTRA  ELSECASE  FOUND  FOR  CASE  FIGURE  DISCARDED. 

MSG  115  UNIT  unit-name  LINE  line-nbr 

CASE  STATEMENT  FOUND  AFTER  ELSECASE 
WILL  NOT  BE  EXECUTABLE. 

MSG  116  UNIT  unit-name  LINE  line-nbr 

EXTRA  ELSE  STATEMENT  FOR  IF  FIGURE  DISCARDED. 

MSG  117  UNIT  unit-name  LINE  line-nbr 

new-f lgure  ENCOUNTERED  BEFORE  IF  FIGURE  TERMINATED. 
ENDIF  ASSUMED  PRECEDING  nev-flgure. 

MSG  118  UNIT  unit-name  LINE  line-nbr 

new-f igure  ENCOUNTERED  BEFORE  DO  FIGURE  TERMINATED. 
ENDDO  ASSUMED  PRECEDING  new-f lgure. 

MSG  119  new-f lgure  ENCOUNTERED  BEFORE  CASE  FIGURE  TERMINATED. 
ENDCASE  ASSUMED  PRECEDING  new-f lgure. 

MSG  120  UNIT  unit-name  LINE  line-nbr 
UNMATCHED  new-f lgure  DELETED. 

MSG  121  UNIT  unit-name  LINE  llne-nbr 

EXPECTED  CASE  NUMBER.  FOUND  WORD  uaer-word. 

WORD  DISCARDED. 

MSG  122  UNIT  unit-name  LINE  line-nbr 

OPTION  CARD  input -card- image  IN  ERROR. 

DEFAULT  OPTIONS  -  NOSOURCE,  MAP  -  ASSUMED. 

MSG  123  UNIT  unit-name  LINE  llne-nbr 

NEST-STACK  OVERFLOWED.  MAXIMUM  NUMBER  OF  NESTED 
STRUCTURED  FIGURES  50  EXCEEDED.  FATAL  ERROR. 
EXECUTION  TERMINATED. 

MSG  124  UNIT  unit-name  LINE  line-nbr 

CONDITION-STACK  OVERFLOWED.  NESTED  DO  CONDITIONS 
OCCUPY  MORE  THAN  MAXIMUM  50  LINES.  FATAL  ERROR. 
EXECUTION  TERMINATED. 
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MSG  125  UNIT  unit-name  LIME  llne-nbr 

CASE-STACK.  OVERFLOWED.  MAXIMUM  NUMBER  OF  NESTED 
CASES  10  EXCEEDED.  FATAL  ERROR.  EXECUTION 
TERMINATED. 

MSG  126  UNIT  unit-name  LINE  line-nbr 

CASE-LABEL-STACK  OVERFLOWED.  MAXIMUM  NUMBER  OF  CASE 
NUMBERS  200  EXCEEDED.  FATAL  ERROR.  EXECUTION 
TERMINATED. 

MSG  127  UNIT  unit-name  LINE  line-nbr 

LABEL-STACK  OVERFLOWED.  MAXIMUM  LABELS  125  EXCEEDED. 
CAUSED  BY  TOO  MANY  NESTED  STRUCTURE  FIGURES. 

FATAL  ERROR.  EXECUTION  TERMINATED. 

MSG  128  UNIT  unit-name  LINE  line-nbr 

OUTPUT-STACK  OVERFLOWED.  PROBABLY  CAUSED  BY  TOO  MANY 
BLANK  OR  CONTINUATION  LINES  FOR  ONE  STATEMENT.  FATAL 
ERROR.  EXECUTION  TERMINATED. 

MSG  129  UNIT  unit-name  LINE  line-nbr 

PROCEDURE  DIVISION  NOT  FOUND.  FATAL  ERROR.  EXECUTION 
TERMINATED. 

MSG  130  UNIT  unit-name  LINE  line-nbr 

MAXIMUM  NUMBER  OF  STRUCTURE  FIGURES  9999  EXCEEDED. 
FATAL  ERROR.  EXECUTION  TERMINATED. 

MSG  132  UNIT  unit-name  LINE  line-nbr 

ERROR  IN  FORMAT  OF  INCLUDE  CARD  IN  LINK  UNIT 
input- card -image 

MSG  163  UNIT  unit-name  LINE  line-nbr 

NON-COMMENT  WITH  PUNCH  IN  COLUMN  6  WITHOUT  A 
PRECEEDING  STATEMENT  CARD 

MSG  164  UNIT  unit-name  LINE  line-nbr 

END  IF  before  IF,  IF  THEN,  on  ELSE  encountered. 

MSG  165  UNIT  unit-name  LINE  line-nbr 

END  WHILE  ON  ENDDO  before  DO  WHILE  encountered 

MSG  166  UNIT  unit-name  LINE  line-nbr 

END  CASE  before  CASE  OF,  CASENTRY ,  CASE,  CASE  ELSE, 
or  ELSE  CASE  encountered 
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Mag. 

MSG  167 

MSG  168 

MSG  169 

MSG  170 

MSG  171 

MSG  172 

MSG  173 

MSG  174 

MSG  175 

MSG  176 

MSG  177 

MSG  178 

MSG  179 

MSG  180 


Message  Text 

UNIT  unit-name  LINE  line-nbr 

END  UNTIL  or  ENDDO  before  DO  UNTIL  encountered 

UNIT  unit-name  LINE  line-nbr 
ELSE  after  ELSE 

UNIT  unit-name  LINE  line-nbr 
CASE  after  CASE  ELSE  or  ELSE  CASE 

UNIT  unit-name  LINE  line-nbr 

CASE  ELSE  after  CASE  ELSE  or  ELSE  CASE:  or 

ELSE  CASE  after  CASE  ELSE  or  ELSE  CASE 

UNIT  unit-name  LINE  line-nbr 
ELSE  before  IF  encountered 

UNIT  unit-name  LINE  line-nbr 

CASE  before  CASE  OF  or  CASENTRY  encountered 

UNIT  unit-name  LINE  line-nbr 

Structural/ syntactic  error  in  program,  cause  unknown 
UNIT  unit-name  LINE  line-nbr 

CASE  ELSE  before  CASE  OF,  CASENTRY,  or  CASE  encountered 
UNIT  unit-name  LINE  line-nbr 

ENDDO  statement  encountered  not  preceeded  by  a 
DO  WHILE  or  DO  UNTIL  statement 

UNIT  unit-name  LINE  line-nbr 

Character  string  too  long  in  CASE  statement 

UNIT  unit-name  LINE  line-nbr 

Program  END  without  balancing  blocks  for  each 
statement 

UNIT  unit-name  LINE  line-nbr 
Improperly  nested  DMATRAN  statements 

UNIT  unit-name  LINE  line-nbr 

Cause  unknown.  Unrecognizable  statement. 

UNIT  unit-name  LINE  line-nbr 
INCLUDE  statement  error  encountered 
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MSG  181  UNIT  unit-name  LINE  line-nbr 

ERROR  encountered  when  attempting  to 
retrieve  a  stub  unit. 


PSL012  BLOCK  NUMBER  TO  BE  RELEASED  IS  NOT  IN  RANGE  UNDER 
LIBRARY-library-name  SECT ION-s act ion-name 
BLOCK  block-nbr  FILE  file-nbr 

PSL021  BLOCK  NUMBER  IN  ERROR  FOR  WRITE  ON  SECTION  FILE 
BLOCK  block-nbr  FILE  file-nbr 
PROJECT-pro ject-name  LIBRARY ■library-name 
SECT ION-8 ec t ion-name  UNIT-unlt-name 

PSL022  INVALID  FILE  NUMBER  file-nbr 

PSL024  UNABLE  TO  ADD  ENTRY  TO  INDEX  FOR  UNIT  unit-name 

PSL027  UNABLE  TO  LOCATE  DIRECTORY  FOR 
LIBRARY-library-name 
SECT ION ■sect ion-name 
BLOCK  block-nbr  FILE  file-nbr 

PSL029  ERROR  WHILE  CHANGING  INDEX  ENTRY 

PSL031  ERROR  WHILE  FINDING  INDEX  ENTRY 

PSL033  UNABLE  TO  READ  BLOCK  block-nbr  FILE  file-nbr 

PSL034  UNABLE  TO  WRITE  BLOCK  block-nbr  FILE  file-nbr 

PSL037  UNABLE  TO  RELEASE  FILE  WITH 

ACCESS-access-mode  FILE“f ile-nbr 

PRO JECT-pro ject -name  LIBRARY-library-name 

SECT ION-3 ect ion-name  UNIT-unlt-name 

PSL038  ILLEGAL  PROCESS  TYPE  FOR  INCLUDE.  PROCESS  TYPE 
MUST  BE  ADD  OR  DELETE. 

PSL039  UNABLE  TO  DELETE  INCLUDE  FOR  UNIT-unlt-name 

PSL040  UNABLE  TO  ADD  INCLUDE  FOR  UNIT-unlt-name 

PSL041  UNABLE  TO  ASSIGN  BLOCK  IN 

LIBRARY-library-name  SECTION -sec t ion-name 
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Msg . 

Key..- 

PSL042 

PSL043 

PSL044 

PSL045 

PSL046 

PSL047 

PSL048 

PSL049 

PSL051 

PSL052 

PSL073 

PSL074 

PSL089 

PSL094 

PSL096 

PSL139 


Message  Text 

UNABLE  TO  RELEASE  BLOCK.  IN 

LIBRARY" library-name  SECTION "section -name 

UNABLE  TO  INITIALIZE  WRITE  FOR  UNIT-unlt-name 

UNABLE  TO  WRITE  LINE  FOR  UNIT-unlt-name 

UNABLE  TO  TERMINATE  WRITE  FOR  UNIT-unlt-name 

UNABLE  TO  WRITE  ACCOUNTING  INFORMATION  FOR 
UNIT-unit-name 

UNABLE  TO  INITIALIZE  READ  FOR  UNIT-unlt-name 
UNABLE  TO  READ  LINE  FOR  UNIT-unlt-name 
UNABLE  TO  TERMINATE  READ  FOR  UNIT-unlt-name 
UNABLE  TO  READ  INDEX 

FILE  f ile-nbr  BLOCK  block-nbr  DIRECTORY  yes-or-no 

UNABLE  TO  SPAWN  JOB  TO  COMPLETE  PROCESSING 

NESTING  OF  READS  EXCEEDS  (max-nest-level)  LEVELS 

INVALID  ACCESS-access-mode  FOR  UNIT  TYPE-unlt-type 

ILLEGAL  PSL  CARD  PROCESSING  AFTER  END  OF  PSL  INPUT 

INVALID  BLOCK  NUMBER  FOR  RANDOM  FILE  ACCESS 
BLOCK  block-nbr  FILE  file-nbr 

UNABLE  TO  GENERATE  STUB  FOR  INCLUDED  UNIT. 

DID  NOT  DELETE  UNIT-unit-name 

RECORD-SEQUENCE-ERROR  ENCOUNTERED  ON  BACKUP  TAPE  AT 
RECORD-SEQUENCE-NBR-seq-number  ON 
RECORD-TYPE-NBR- type-number 
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APPENDIX  D. 


PSL  PROCEDURES 


The  following  pages  of  Appendix  D  contain  the  JCL  procedures  which  are 
provided  with  the  PSL  system  to  invoke  the  PSL  programs.  The  procedures, 
which  are  stored  as  units  in  the  JOB  section,  are  as  follows: 


a. 

ASM 

- 

Assembles  ASM  code. 

b. 

RUN 

- 

Invokes  the  Batch  PSL  system. 

c . 

CLMD 

- 

Collects  management  data. 

d. 

COBOL 

- 

Compiles  COBOL  code  without  using  a  precompiler. 

e. 

FORTRAN 

- 

Compiles  FORTRAN  code  without  using  a  precompiler. 

f. 

MD 

- 

Prints  Management  Data  report. 

g- 

PS 

- 

Print  Program  Structure  report. 

h. 

SCOBOL 

- 

Processes  COBOL  code  with  precompiler  and 
compiles  resulting  code. 

i. 

SPFORT 

- 

Processes  COBOL  code  with  recompiler  and  compiles 
resulting  code. 

J. 

COBOLG 

- 

Processes  unstructured  COBOL  using  the  General 
Preprocessor  and  compiles  resulting  code.* 

k. 

FORTRANG 

- 

Processes  unstructured  FORTRAN  using  the  General 
Preprocessor  and  compiles  resulting  code.* 

1. 

PSLCOB 

- 

Processes  COBOL  code  with  precompiler  COPYLIB 
and  compiles  resulting  code. 

m. 

ASMG 

- 

Processes  unstructured  ASM  using  the  General 
Preprocessor 

and  compiles  resulting  code.* 

Each  of  the  procedures,  except  RUN,  is  used  in  a  spawned  job  and  is 
modified  by  the  PSL  system  to  reference  appropriate  file  names  before 
the  procedure  is  spawned. 


*See  Appendix  I. 


FIGURE  D-01  PROCEDURE  ASM 


A0-A107  299 


F/0  9. 


unclassified 


IBM  FEDERAL  SISTERS  OIV  9AITMERSBURG  MO 
PMOORAMMINR  SUPPORT  LIBRARY  (PSL>.  USERS  MANUAL. (U) 

M,t  7“  FS0602-77-C-0299 

OOO/OF-RI/OIBA  NL 


so-a  naou 


90-a  nou 


LO-a  naan 


FIGURE  D-08 


•  V- 

•  •  *  a.  er  ft 

u.  •  </>  •  •  o  ►-  a.  a  u.  • 

u.u  _i</'nu3  •  *  • 

u.  _i  cl  o  -J  a  c.  »  »  h-  • 

U  U.  M,  l  I/;  a.  j  a  w  j  <j 

U«iO«tK  ►>-«u.  o  -J  (/■  u 

»»*»»«  u  u  *■ 


o  v  c>  u  c  u  it  uj  >.  &.  a  o  u. 
n<'.  tun  «2n.u  or.  >•  w  ct  o 

m  <w  «*  «  «  tJ  l.  x  u.  u  v.  ui  l.  «  u. 

a  »  -  .n  i  .»•  Ct»  c -  •  i  u*  <•«  t*  *.ii  *o 

H  fi  to  4  tfi  vD  ^  (b  U'  c  h  M  K)  <  ta* 


D-13 


FIGURE  D-I2 


»•* 

• 

a 

Vi 

• 

•  u 

U 

• 

•  *  u 

a 

a. 

•  vi  •  •  O  ►-  U 

u  •  •  *  u  a-  o 

ft  a.  •  vt  •  •  w  u  II  o  u  • 

t'lft.O'  _J  Ui  O  U  D  •  •  •  u 

a;  a.  -J  u.  u.  _j  c.  v,  *  •  (-•)  • 

o  a  ft  h  vi  u.  J  a.  v<  h  o 

u  u  <  i.  «  i-  » *->  a  a  -j  •  a. 

»»>*»<  U  U  c 

».  ij  V  1}  i4  f  I*  ft  hUU  )i  1.  IJ  It. 

V>  </.  W  W  V  *  C  lift.  Ci  C 

3  <  ti  «  <  «  d  u  x  k.  h.  wo  «i:  «•  '«iij 

u.  u.  •*  <«  *».  *•••  '•»  >rt  •<*  *»  w  «•'  C' 


H  (g  M  »  1(1  M)  I*  «  tr  Cl  IM  iv  Kl  ♦  1.1  Vi) 

rt  H  fl  H  H  H  H 


FIGURE  D-13  PROCEDURE  PSLCOB 


APPENDIX  E. 


FILE  NAMES 


The  following  file  nines  are  used  by  the  PSL  system: 
a.  Regular  Processing  (not  spawned) 


1. 

CC 

Input  of  PSL  Function  cards  and  data 

2. 

CHF 

Temporary  worlc  file 

3. 

F1-F3 

Independent  unit  files  (sequential) 

4. 

FJ 

JCL  for  spawned  job 

5. 

FS 

Temporary  work  file 

6. 

JS 

Temporary  work  file 

7. 

MS 

Listing  of  Input  cards  and  messages 

8. 

R1-R4 

PSL  Standard  files  (random) 

9. 

R0 

PSL  Standard  file  (random) 

10. 

RT 

Input  to  RESTORE 

11. 

TF 

Temporary  work  file 

12. 

UC 

Punched  card  output  (SOURCE .MEDIA-CARD) 

13. 

UL 

Listings  of  units  and  Indexes 

14. 

UT 

BACKUP  output  or  output  from 
(SOURCE .MEDIA-TAPE) 

15. 

XA 

Sort  work  file 

16. 

XF 

Vork  file 

Spawned  Jobs 

1. 

02 

Generated  source  code  for  Input  to 

FORTRAN  compiler 

2. 

CC 

Input  of  PSL  Function  cards  and  data 

3. 

JV 

Output  from  COMPOOL  assembly 

4. 

J0-J9 

C0MP00L  input  files  (symbol  tables) 

5. 

F1-F3 

Independent  unit  files 

6. 

LS 

Program  structure  report 

7. 

MS 

Message  listing 

8. 

NC 

New  collection  -  vork  file 

9. 

PX 

Plan  keywords  -  vork  file 

10. 

PO 

Generated  source  code  for  input  to  compiler 

11. 

PR 

Message  output 

12. 

R1-R9 

PSL  Standard  files  (random) 

13. 

RC 

Random  collection  -  vork  file 

14. 

XA 

Sort  vork  file 

15. 

XF 

Work  file 

APPENDIX  F.  USERS  MANUAL  FOR  PSL  STRUCTURED  FORTRAN  PRECOMPILER 


The  following  pages  of  this  appendix  provide  the  relevant 
information  on  the  FORTRAN  precompiler  of  the  PSL.  This 
precompiler  was  developed  under  the  name  of  STRUCTRAN-1*  by 
General  Research  Corporation  for  RADC,  and  has  been  installed 
in  the  PSL  by  IBM. 

F • 1  Introduction 

The  techniques  of  Structured  Programming  are  finding  increasing 
application  in  the  computing  community.  Structured  programs 
are,  however,  difficult  to  write  in  programming  languages  that 
do  not  have  the  statement  types  necessary  to  produce  GOTO-free 
code.  SPFORT  is  a  programming  language  that  augments  standard 
FORTRAN  to  permit  its  use  as  a  basis  for  structured  programming. 
Six  structured  programming  statement  forms  are  provided  for  use 
in  FORTRAN-based  .software  development.  The  FORTRAN  preprocessor 
translates  SPFORT  into  standard  FORTRAN.  It  accepts  as  input 
modules  containing  both  SPFORT  and  FORTRAN  statements,  and 
produces  as  output  Indented  pure-FORTRAN  modules  logically 
equivalent  to  the  input  modules.  Features  Include  error  process¬ 
ing  to  warn  of  improper  statement  forms,  and  warnings  to  indicate 
the  presence  of  unstructured  FORTRAN  control  statements. 

The  structured-programming  statement  forms  implemented  In  the 
FORTRAN  precompiler  are  described  In  Section  F.2,  with  typical 
examples  of  SPFORT  subroutines  and  the  translated  FORTRAN  sub¬ 
routines.  Error  diagnostics  are  described  in  Section  F.3. 

SPFORT  guidelines  are  summarized  in  Section  F.4. 

F . 2  SPFORT  Constructs 

SPFORT  replaces  FORTRAN  control  statements  with  the  following 
control  statement  constructs: 


a.  IF ...  THEN ...  ELSE  ...  END  IF--provides  block  structuring 
of  conditionally  executable  sequences  of  statements. 

b.  DO  WHILE... END  WHILE — permits  iteration  of  a  code 
segment  while  a  specified  condition  remains  true. 


*For  additional  information  regarding  this  capability  as  it 
was  developed,  see  the  Final  Technical  Report,  Structured 
Programming  Translators,  RADC-TR-76-253 ,  Volumes  I  to  V. 
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c.  CASE  OF. . .CASE. . .CASE  ELSE... END  CASE — allows 
multiple  choices  for  selecting  program  action. 

d.  DO  UNTIL... END  UNTIL — permits  Iteration  until  a 
specified  condition  becomes  true. 

e.  BLOCK  NAME... END  BLOCKS  (and  corresponding  INVOKE 
NAME  statement) — provide  Internal  subroutines. 

f.  INCLUDE — provides  for  top-down  programming  and 
Implementation . 

These  statement  ftfrms  can  be  Intermixed  with  standard  FORTRAN 
non-control  statements  In  the  text  stream  which  Is  processed 
by  the  FORTRAN  preprocessor.  SPFORT  statements  are  converted 
by  the  preprocessor  to  their  FORTRAN  equivalents,  and  the 
resulting  file  can  be  compiled  by  the  FORTRAN  compiler  in  the 
normal  manner. 

The  following  simple  examples  Illustrate  the  use  of  these 
control  statements. 

F.2.1  IF. . .THEN. . .ELSE. . .END  IF 

The  general  form  of  the  IF  construct  consists  of  three  SPFORT 
statements : 

IF ( < logical-expression  > ) [THEN] 

<  block  of  statements > 

'ELSE 

<  block  of  statements  > 

ENDIF 

where < logical-expression^ Is  any  legal  FORTRAN  logical 
expression.  The  word  TEHN  Is  optional.  Tha < logical- 
expression  > Is  evaluated,  and  If  it  Is  true,  the  statements 
following  the  IF  are  executed  until  the  ELSE  is  reached, 
where  control  peases  to  the  first  statement  after  the  END  IF. 
The  ELSE  is  optional.  If  the  ELSE  Is  absent  and  the< logical- 
expression  >  is  false,  control  passes  to  the  first  statement 
after  the  END  IF.  If  the  ELSE  Is  present  and  the<  logical- 
express  ion > is  false,  control  passes  to  the  statement  following 
the  ELSE  so  that  the  statements  after  the  ELSE  are  executed. 

An  example  SPFORT  subroutine  containing  the  IF  construct  is 


presented  In  Figure  F-Ola.  An  alternate  format  for  writing 
the  IF  construct  Is  shown  In  Figure  F-Olb.  The  STRUCTRAN-1 
translation  of  the  example  subroutine  la  presented  In 
Figure  F-Olc. 

F.2.2  DO  WHILE. . . END  WHILE 

The  general  form  of  the  DO  WHILE  construct  consists  of  two 
SPFORT  statements: 

DO  WHILE (< logical-expression  > ) 

<  block  of  statements  > 

END  WHILE 

where < logical-expression > is  any  legal  FORTRAN  logical 
expression.  The  DO  WHILE  construct  represents  an  Iteration 
In  which  execution  occurs  In  the  following  manner: 

a.  The  value  of  logical-expression  Is  found:  if 
true,  the  statements  contained  within  the  DO  WHILE 
block  are  executed;  If  false,  control  passes  to  the 
statement  Immediately  following  the  END  WHILE. 

b.  If  the  statements  within  the  DO  WHILE  block  have 
been  executed,  the  value  of  logical-expression  is 
checked  again,  with  the  same  consequences  as  In  a. 

The  Iterative  block  In  the  DO  WHILE* • • END  WHILE  may  be 
executed  zero  or  more  times.  In  general.  It  Is  necessary  to 
initialize  the  loop  control  variable  before  entering  the  DO 
WHILE  construct,  and  also  necessary  to  modify  It  within  the 
DO  WHILE  construct.  An  example  SPFORT  subroutine  containing 
the  DO  WHILE  construct  is  presented  In  Figure  F-02a.  An 
alternate  format  for  writing  this  construct  Is  shown  In 
Figure  F-02b.  The  FORTRAN  preprocessor  generates  the  trans¬ 
lation  of  the  example  subroutine  presented  in  Figure  F-02c. 

The  IF  construct  and  the  DO  WHILE  construct  are  sufficient  to 
express  the  control  portion  of  any  algorithm  which  can  be 
implemented  In  FORTRAN.  However,  for  greatest  convenience  in 
Implementation  of  software  systems  with  structured  program¬ 
ming  techniques,  some  additional  statement  forms  are  highly 
desirable.  The  CASE  construct  Is  a  selection  structure  and 
the  DO  UNTIL  Is  an  Iteration  structure,  while  the  BLOCK 
construct  enhances  modularity. 


(a)  SUBROUTINE  IFTHEN  (IN, OUT) 
INTEGER  OUT 
IF  (IN .GE . 10)  THEN 
OUT-O 
ELSE 

OUT-OUT+1 
END  IF 
RETURN 
END 


(c)  SUBROUTINE  IFTHEN  (IN, OUT) 

INTEGER  OUT 

IF  (IN  .GE . 10 )  GO  TO  99998 
GO  TO  99997 
99998  CONTINUE 
OUT-O 

GO  TO  99996 
99S97  CONTINUE 

OUT-OUT+1 
99996  CONTINUE 
RETURN 
END 


Figure  F-01.  SPFORT  IF  ...  THEN  ...  ELSE  ... ENDIF 

Conatruct  With  FORTRAN  Preprocessor 
Translation 


/ 
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(a)  SUBROUTINE  DOWHILE  (IN .OUT, I) 
INTEGER  OUT 
DIMENSION  IN (50) 

1-1 

DO  WHILE  (IN  (I) .NE.OUT .AND . I . LE .50) 
I-I+l 
END  WHILE 
RETURN 
END 


(b)  SUBROUTINE  DOWHIL  (IN, OUT, I) 
INTEGER  OUT 
DIMENSION  IN (50) 

1-1 

DOWHILE  (IN (I) . NE.OUT. AND. I. LE . 50) 
I-I+l 
ENDDO 
RETURN 
END 


(c)  SUBROUTINE  DOWHILE  (IN, OUT, I) 

INTEGER  OUT 
DIMENSION  IN(50) 

1-1 

99998  IF  (IN(I) .NE .OUT . AND . I . LE . 50)  GO  TO  99997 
GO  TO  99996 
99997  CONTINUE 
I-I+l 

GO  TO  99998 
99996  CONTINUE 
RETURN 
END 


Figure  F-02 .  SPFORT  DO  WHILE... END  WHILE  Constructs 
With  FORTRAN  Preprocessor  Translation 


F-5 


The  CASE  iteteaent  provides  e  way  to  select  which  group  of 
statements  will  be  executed.  The  general  fora  of  the  CASE 
construct  consists  of  the  following  SPFORT  steteaents: 

CASE  OF (<  integer-expression > ) 

CASE (<  i>) 

CASE (<  j  >) 

<  block  of  steteaents  > 

CASE  ELSE 

<  block  of  steteaents  > 

END  CASE 

<  i>  and<  J  >  represent  integers  of  positive  value.  They  aey 
be  in  any  order,  and  there  is  no  limit  to  how  many  integers 
aay  be  listed.  In  a  list  of  Integers  appearing  on  the  saae 
CASE  statement,  coaaes  are  required  between  Integers. 

The<  integer-expression > is  computed,  and  if  any  of  the 
specified  Integers  in  the  CASE  list  are  equal  to  the  value 
of  the  expression,  then  the  transfer  of  control  is  to  the 
statements  which  follow  the  particular  CASE.  If  there  is  no 
such  CASE,  end  the  CASE  ELSE  stateaent  is  present,  then  the 
block  of  steteaents  following  the  CASE  ELSE  is  executed; 
otherwise,  no  block  is  executed.  If  there  are  two  CASE 
statements  with  the  seme  CASE  index,  the  first  occurring  one 
is  executed  (if  the  CASE  expression  has  that  value).  After 
the  block  of  statements  sslected  has  been  executed,  control 
transfers  to  the  stateaent  sfter  the  END  CASE. 

An  example  SPFORT  subroutine  containing  the  CASE  construct 
is  presented  in  Figure  F-03s.  An  alternate  fora  of  writing 
this  construct  is  shown  in  Figure  F-03b.  The  FORTH/ N  pre¬ 
processor  produces  the  translation  of  the  example  subroutine 
shown  in  Figure  F-03c. 

F.2.4  DO  UNTIL. . .END  UNTIL 

The  general  fora  of  the  DO  UNTIL  construct  consists  of  two 
SPFORT  steteaents: 


(a)  SUBROUTINE  CASE  (IN, OUT) 
INTEGER  OUT 
CASE  OF  (IN) 

CASE  (10) 

OUT- IN 
CASE  (15) 

OUT- IN-3 
CASE  ELSE 

OUT- IN+10 
END  CASE 
RETURN 
END 


(b)  SUBROUTINE  CASE  (IN, OUT) 
INTEGER  OUT 
CASENTRY  (IN) 

CASE  (10) 

OUT-IN 
CASE  (15) 

OUT-IN-3 
ELSECASE 
OUT- IN+10 
END CASE 
RETURN 
END 


(c)  SUBROUTINE  CASE  (IN, OUT) 

INTEGER  OUT 
199998-IN 

IF  (199998. NE. (10))  GO  TO  99996 
OUT-IN 
GO  TO  99997 

99996  CONTINUE 

IF  (199998. NE. (15))  GO  TO  99995 
OUT-IN-3 
GO  TO  99997 
99995  CONTINUE 

OUT- IN+10 

99997  CONTINUE 
RETURN 

END 


Figura  F-03 .  SPFORT  CASE  Conatruct  Vlth  FORTRAN 
Praprocaaaor  Translation 


<  block  of  statements  > 


END  UNTIL 

The  statements  enclosed  within  the  DO  UNTIL  and  the  END  UNTIL 
are  always  executed  once.  Then  the  <  logical-expression > is 
evaluated  and ,  if  false,  iteration  and  evaluation  of  the 
expression  continue  until  it  is  true.  At  that  time  execution 
of  the  statements  following  the  END  UNTIL  begins. 

An  example  SPFORT  subroutine  containing  the  DO  UNTIL  construct 
is  presented  in  Figure  F-04a.  An  alternate  format  for  writing 
this  construct  is  presented  in  Figure  F-04b.  The  FORTRAN 
preprocessor  produces  the  translation  of  this  subroutine  shown 
in  Figure  F-04c.  After  completion  of  the  DO  UNTIL  Iteration, 

<  J>  will  have  the  value  16  and<I>the  value  11.  It  is 
important  to  note  that  when  using  DO  WHILE  or  DO  UNTIL 
constructs,  the  iteration  variable  must  be  initialized  before 
entering  the  iteration  and  modified  within  the  iteration. 

F . 2 . 5  BLOCK... END  BLOCK  and  INVOKE 

The  constructs  described  in  the  preceding  paragraphs  allow 
most  programming  tasks  to  be  done  in  a  well-structured  manner. 
However,  they  do  not  always  permit  top-down  programming.  To 
Implement  this  method,  one  must  be  able  to  refer  to  an  action 
(such  as  "compute  array  element")  before  the  code  for  it  is 
actually  available. 

The  usual  method  for  doing  this  is  calling  subroutines.  However, 
subroutines  have  certain  disadvantages.  The  overhead  Involved 
in  calling  them  is  often  high.  Additionally,  those  variables 
used  in  both  a  calling  routine  and  a  called  subroutine  must 
either  be  placed  in  COMMON  or  passed  as  parameters. 

In  many  cases,  a  subroutine  uses  only  variables  which  are 
already  in  the  routine  which  calls  it.  Use  of  a  subroutine 
Internal  to  the  calling  routine  eliminates  the  need  for  any 
mechanism  (such  as  parameters  or  COMMON  blocks)  for  referring 
to  the  variables  required. 

A  facility  for  creating  and  using  this  type  of  subroutine  has 
been  added  to  SPFORT.  This  construct  is  called  a  BLOCK  which 
may  be  defined  aa  an  internal  parameterless  procedure  with  all 
variables  global.  A  BLOCK  can  be  called  only  from  the  individual 


(s)  SUBROUTINE  DOUNTL  (IN, OUT) 
DIMENSION  IN (10) 

INTEGER  OUT (20) 

1-1 

J-6 

DO  UNTIL  (I.GT.10) 

OUT (J) “IN (I) 

I-I+l 
J-J+l 
END  UNTIL 
RETURN 
END 


(bj  "UBROUTINE  DOUNTL  (IN, OUT) 
DIMENSION  IN (10) 

INTEGER  OUT (20) 

1-1 

J-6 

DOUNTIL  (I.GT.10) 

OUT (J) -IN (I) 

I-I+l 

J-J+l 

ENDDO 

RETURN 

END 


(c)  SUBROUTINE  DOUNTL  (IN, OUT) 

DIMENSION  IN(10) 

INTEGER  OUT(20) 

1-1 

J-6 

GO  TO  99998 

99997  IF  (I.GT.10)  GO  TO  99996 

99998  CONTINUE 

OUT ( J) -IN ( I) 

I-I+l 

J-J+l 

GO  TO  99997 
99996  CONTINUE 
RETURN 
END 


Figure  F-04.  SPFORT  DO  UNTIL... END  UNTIL  Construct 
With  FORTRAN  Preprocessor  Trensletion 


routine  (mein  program,  subroutine,  or  function)  In  which  It  Is 
complied;  It  cannot  be  called  from  an  external  routine,  nor  can 
It  be  passed  as  a  parameter  to  another  routine.  A  BLOCK.  Is 
simply  a  segment  of  the  code  of  the  routine  which  contains  It. 
The  BLOCK  Is  exercised  only  If  It  Is  Invoked. 

The  general  form  of  a  'BLOCK  construct  consists  of  two  SPFORT 
statements : 

BLOCK( < block-name  >) 

<  statements  > 

END  BLOCK 

where < block-name > Is  any  string  of  characters  (e.g.,  COMPUTE, 
INDEX,  or  PRINT-CURRENT-STATUS).  The  name  of  a  BLOCK  may  be 
arbitrarily  long,  so  that  the  name  can  have  mnemonic  signifi¬ 
cance.  However,  the  first  six  characters  must  be  unique. 

A  BLOCK  Is  called  by  an  INVOKE  statement,  whose  format  Is: 

INVOKE (<  block-name  >) 

When  an  INVOKE  statement  Is  executed,  control  Is  transferred 
to  the  first  statement  In  the  BLOCK;  when  the  END  BLOCK  Is 
reached,  control  goes  to  the  statement  following  the  INVOKE  of 
the  BLOCK.  Though  BLOCKS  can  be  nested  (one  BLOCK  completely 
Inside  of  another),  no  recursion  Is  allowed  In  the  calling  of 
BLOCKS  (l.e.,  a  BLOCK  cannot  Invoke  Itself).  Also,  the  name 
of  a  BLOCK  Is  known  throughout  the  entire  routine  In  which  It 
la  contained. 

The  following  are  examples  of  the  two  major  uses  of  the  BLOCK 
construct : 

Example  1:  Top-Down  Programming 
1-1 

DO  UNTIL  (I  .GT.  N) 

J-l 

DO  UNTIL  (J  .GT.  N) 

INVOKE (COMPUTE .ARRAY . ELEMENT) 

J-J+l 
END  UNTIL 
I- 1+1 
END  UNTIL 
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and,  at  some  place  later  In  the  same  routine: 

BLOCK (COMPUTE .ARRAY . ELEMENT) 
coda  to  compute  A(I,J) 

A ( I , J)  ■  value  computed 
J-J+l 
END  BLOCK 


The  use  of  a  BLOCK  construct  enhances  readability  and  under- 
standablllty  of  the  program.  When  a  block,  of  code  is  Invoked 
only  once,  the  INCLUDE  capability  can  be  conveniently  used  in 
place  of  the  BLOCK  construct. 

Example  2:  Internal  Subroutine 


S i  and  S 2  in  the  following  code  represent  two  seta  of 
statements.  The  use  of  a  BLOCK  in  Method  2  below  eliminates 
the  need  for  duplicating  code. 


Method  1:  IF (A)  THEN 

IF (C )  THEN 


ELSE 

S2 
END  IF 
ELSE 

IF (D)  THEN 


ELSE 


END  IF 
END  IF 


Method  2:  IF (A)  THEN 

IF (C)  THEN 

INVOKE (BLOCK-A) 
ELSE 

INVOKE (BLOCK-B) 
END  IF 
ELSE 

IF  (D)  THEN 

INVOKE (BLOCK-B) 
ELSE 

INVOKE (BLOCK-A) 
END  IF 
END  IF 


where  the  BLOCKS  are  defined  as: 


BLOCK(BLOCK-A) 

S1 

END  BLOCK 


and 


BLOCK (BLOCK-B) 
S2 

END  BLOCK 
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and  the  code  structure  to  be  used  to  represent  the  INCLUDE  Is 


Format 

statement 

numerics 

INCLUDE 

unit-name 

statement 

A  more  detailed  description  of  INCLUDE  statements  is  contained 
in  Section  3.2.8. 


the  FORTRAN  Preprocessor 


Figure  F-06  illustrates  an  SFFORT  source  program  ready  for 
input  to  the  FORTRAN  preprocessor.  The  SFFORT  source  code  has 
not  been  manually  Indented  in  order  to  avoid  the  problem  of 
updating  indentation  levels  as  the  program  is  modified.  More 
than  one  module  may  be  processed  in  each  preprocessor  run. 
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(a)  SUBROUTINE  BLOCK  (WIDTH .LENGTH) 
INTEGER  AREA, WIDTH 
LENGTH-LENGTH+20 
WIDTH-WIDTH+30 
INVOKE  (COMPUTE  AREA) 

INVOKE  (PRINT  AREA) 

BLOCK  (COMPUTE  AREA) 
AREA-LENGTH* WIDTH 
END  BLOCK 
BLOCK  (PRINT  AREA) 

WRITE  (6,1)AREA 
1  FORMAT  (10X.I20) 

END  BLOCK 

RETURN 

END 


(b)  SUBROUTINE  BLOK  (WIDTH , LENGTH) 

INTEGER  AREA, WIDTH 
LENGTH-LENGTH+20 
WIDTH-WIDTH+30 
ASSIGN  99997  TO  199998 
GO  TO  99998 

99997  CONTINUE 

ASSIGN  99995  TO  199996 
GO  TO  99996 

99995  CONTINUE 

GO  TO  99994 

99998  CONTINUE 

AREA-LENGTH* WIDTH 
GO  TO  199998 , (99997) 

99994  CONTINUE 

GO  TO  99993 

99996  CONTINUE 

WRITE  (6 , 1) AREA 
1  FORMAT  (10X.I20) 

GO  TO  199996,(99995) 

99993  CONTINUE 
RETURN 


Figure  F-05 •  SPFORT  INVOKE  ...  BLOCK  Construct  With 
FORTRAN  Preprocessor  Translation 
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SUBROUTINE  EXAMP L  (INFO .LENGTH) 

ILLUSTRATION  OF  SPFORT  SYNTAX 

IF  (INFO. LE. 10  .AND.  LENGTH . GT . 0 ) THEN 

INF0-INF0+1G 

ELSE 

LENGTH-50 
END  IF 

CASE  OF  (INFO+6) 

CASE  (14) 

LENGTH-LENGTH- INFO 
CASE  (17) 

DO  WHILE  (INFO. LT. 20) 

DO  UNTIL  (LENGTH. LE .INFO) 

INVOKE  (COMPUTE  LENGTH) 

IF  (LENGTH. GE. 30)  THEN 
INVOKE  (PRINT-RESULTS) 

END  IF 
END  UNTIL 
INFO- INFO+1 
END  WHILE 
CASE  ELSE 

DO  WHILE  (LENGTH. GT.O) 

INVOKE  (COMPUTE  LENGTH) 

END  WHILE 
END  CASE 

BLOCK  (PRINT-RESULTS) 

WRITE  (6, l)INFO, LENGTH 
1  FORMAT  (10X , 15 , 20X , 15 ) 

END  BLOCK 

BLOCK  (COMPUTE  LENGTH) 

LENGTH- LENGTH- 10 
END  BLOCK 
RETURN 
END 


EXAMPL1 

EXAMPL2 

EXAMPL3 

EXAMPL4 

EXAMPL5 

EXAMP L 6 

EXAMPL7 

EXAMPL8 

EXAMPL9 

EXAMPL10 

EXAMPL11 

EXAMPL12 

EXAMPL13 

EXAMPL14 

EXAMPL15 

EXAMPL16 

EXAMPL1 7 

EXAMPL18 

EXAMPL19 

EXAMPL20 

EXAMPL21 

EXAMPL22 

EXAMPL23 

EXAMPL24 

EXAMPL25 

EXAMPL26 

EXAMPL2  7 

EXAMPL28 

EXAMPL29 

EXAMPL30 

EXAMP L31 

EXAMP L3 2 

EXAMP L3 3 

EXAMPL34 

EXAMPL35 

EXAMPL36 


Figure  F-06.  FORTRAN  Preprocessor  Input 


Figure  F-07  illustrates  the  translated  FORTRAN  version  of 
Figure  F-06  produced  by  the  preprocessor.  This  nay  be 
compiled  and  executed  in  the  normal  manner.  The  translated 
FORTRAN  is  Indented  to  reflect  the  structure  of  the  original 
SPFORT  program.  The  sequence  Information  In  columns  73 
through  80  refers  back  to  the  card  number  of  the  original 
SPFORT  statement.  This  aids  in  relating  FORTRAN  error 
diagnostics  to  the  SPFORT  source  code  to  be  modified. 

A  list  and  description  of  the  error  messages  are  provided  in 
Table  F-l. 


F . 4  Guidelines 


The  following  guidelines  should  be  kept  in  mind  when  using 
the  FORTRAN  preprocessor: 

a.  A  maximum  of  20  cards  per  statement. 

b.  The  FORTRAN  preprocessor  generates  FORTRAN  GOTO 
statenfents  and  statement  labels.  Statement  labels 
in  the  SPFORT  input  source  (FORMAT  statements) 
should  not  duplicate  the  labels  appearing  in  the 
translated  FORTRAN. 

c.  When  the  DO  UNTIL... END  UNTIL  construct  is  used  fo«- 
iteration,  it  is  Important  to  note  that  the  state" 
ments  contained  within  the  construct  will  be 
executed  once  before  the  logical  expression  is 
evaluated . 

d.  All  two  word  SPFORT  directives  may  be  written  as 

two  separate  words  or  merged  into  one;  e.g.,  DOUNTIL 
or  DO  UNTIL. 

e.  A  maximum  of  20  BLOCKS  per  module. 

f.  A  limit  of  15  INVOKES  for  any  one  BLOCK. 

g.  INVOKE  for  the  BLOCK  must  occur  before  the  BLOCK 
code  (suggest  BLOCKS  be  grouped  at  the  end  of  the 
routine) . 

h.  First  six  characters  of  the  name  of  a  BLOCK  must  be 
unique  within  a  module. 


i. 


Maximum  nexting  level  for  indentation  of  FORTRAN 
output  is  10. 


SUBROUTINE  EXAMFL  (INFO .LENGTH) 

1* 

IF  (INFO. LE. 10  .AND.  LENGTH. GT.O)  GO  TO  99998 

5* 

GO  TO  99997 

5* 

99998 

CONTINUE 

5* 

INFO-INFO+IO 

6* 

GO  TO  99996 

7* 

99997 

CONTINUE 

7* 

LENGTH-50 

8* 

99996 

CONTINUE 

9* 

I99995-INFO+6 

10* 

IF  (199995. NE.  (14))  GO  TO  99993 

11* 

LENGTH-LENGTH- INFO 

12* 

GO  TO  99994 

13* 

99993 

CONTINUE 

13* 

IF  (199995. NE. (17))  GO  TO  99992 

13* 

99991 

IF  (INFO. LT. 20)  GO  TO  99990 

14* 

GO  TO  99989 

14* 

99990 

CONTINUE 

14* 

GO  TO  99988 

15* 

99987 

IF  (LENGTH. LE. INFO)  GO  TO  99986 

15* 

99988 

CONTINUE 

15* 

ASSIGN  99983  TO  199984 

16* 

GO  TO  99984 

16* 

99983 

CONTINUE 

16* 

IF  (LENGTH. GE . 30)  GO  TO  99982 

17* 

GO  TO  99981 

17* 

99982 

CONTINUE 

17* 

ASSIGN  99979  TO  199980 

18* 

GO  TO  99980 

18* 

99979 

CONTINUE 

18* 

99981 

CONTINUE 

19* 

GO  TO  99987 

20* 

99986 

CONTINUE 

20* 

99985 

CONTINUE 

20* 

INFO- INFO+1 

21* 

GO  TO  99991 

22* 

99989 

CONTINUE 

22* 

GO  TO  99994 

23* 

99992 

CONTINUE 

23* 

99978 

IF  (LENGTH. GT.O)  GO  TO  99977 

24* 

GO  TO  99976 

24* 

Figure  F-07 .  Trenelated  FORTRAN 


99977 

CONTINUE 

24* 

ASSIGN  99975  TO  199984 

25* 

GO  TO  99984 

25* 

99975 

CONTINUE 

25* 

GO  TO  99978 

26* 

99976 

CONTINUE 

26* 

99994 

CONTINUE 

27* 

GO  TO  99974 

28* 

99980 

CONTINUE 

28* 

WRITE  (6, 1)INF0, LENGTH 

29* 

1 

FORMAT  (10X , 15 , 20X , 15 ) 

30* 

GO  TO  199980, (99979) 

31* 

99974 

CONTINUE 

31* 

GO  TO  99973 

32* 

99984 

CONTINUE 

32* 

LENGTH* LENGTH- 10 

33* 

GO  TO  199984,(99983,99975) 

34* 

99973 

CONTINUE 

34* 

RETURN 

35* 

END 

36* 

Figure  F-07.  Translated  FORTRAN  (Continued) 
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The  velue  of  integer-expression  in  CASE  state¬ 
ments  oust  be  positive. 


I 

I 

[ 

I 

I 


k.  BLOCK  constructs  cannot  contain  labeled  statements 
which  are  referred  to  outside  of  the  BLOCK. 

l.  A  BLOCK  cannot  be  entered  by  falling  into  it  (as 
the  next  executable  statement). 


i 

I 

I 

r 

E 

[ 

I 

I 

I 


r-i8 


.  -s 


ERROR  NUMBER 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 


ERROR  MESSAGE  DESCRIPTION 

Continuation  card  encountered  without  a 
preceding  stateaent  card. 

END  IF  before  IF,  IF  THEN,  or  ELSE 
encountered . 

END  WHILE  or  ENDDO  before  DO  WHILE 
encountered . 

END  CASE  before  CASE  OF,  CASENTRY ,  CASE, 
CASE  ELSE,  or  ELSE  CASE  encountered. 

END  UNTIL  or  ENDDO  before  DO  UNTIL 
encountered . 

ELSE  after  ELSE. 

CASE  after  CASE  ELSE  or  ELSE  CASE. 

CASE  ELSE  after  CASE  ELSE  or  ELSE  CASE; 
or  ELSE  CASE  after  CASE  ELSE  or  ELSE  CASE. 

ELSE  before  IF  encountered. 

CASE  before  CASE  OF  or  CASENTRY 
encountered . 

Structural/syntactic  error  in  program, 
cauae  unknown*. 

CASE  ELSE  before  CASE  OF,  CASENTRY,  or 
CASE  encountered. 

ENDDO  atateaent  encountered  not  preceded 
by  e  DO  WHILE  or  DO  UNTIL  atateaent. 


*This  occura  when  the  Indentation  level  computed  by  the  pre- 
proceaaor  would  becoae  negative  if  the  error  waa  not  detected. 
Possible  cauaea  are  too  aany  ELSE,  END  IF,  END  WHILE,  END 
UNTIL,  or  END  CASE  atateaenta. 


Table  F-l .  Error  Message  Definitions 
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t 

l 


[ 

r 

L 

i 

i 

i 

i 


ERROR  NUMBER 

176 

177 

178 

179 

180 
181 


ERROR  MESSAGE  DESCRIPTION 

Character  string  too  long  in  CASE 

statement . 

Program  END  without  balancing  blocks  for 
each  statement. 

Improperly  nested  stateaents. 

Cause  unknown.  Unrecognisable  stateaents. 

INCLUDE  statement  error  encountered. 

Error  encountered  when  attempting  to 
retrieve  a  stub  unit. 


I 

I 


* 


Table  F-l .  Error  Message  Definitions  (Continued) 
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APPENDIX  G.  USERS  MANUAL  FOR  PSL  STRUCTURED  COBOL  PRECOMPILER 


G .  1  Prtcoapllar  Objectives 

The  objective  of  the  ANS  COBOL  precompiler  le  to  essist  the 
ueer  In  writing  this  language  In  a  structured  format.  While 
the  basic  control  logic  figures  required  to  accomplish  this 
can  be  simulated  In  the  COBOL  language  (refer  to  "Programming 
Language  Standards",  Volume  I  of  the  Structured  Programming 
Series),  the  simulation  of  these  figures  Is  not  as  desirable 
as  if  the  language  Itself  permitted  the  Implementation  of 
such  control  logic  directly.  This  is  particularly  true  of 
the  DO  and  CASE  figures.  When  using  the  DO  figure  with  the 
precompiler,  the  user  may  place  the  code  block  under  control 
of  the  loop  in-line  rather  than  simulating  it  with  a  PERFORM 
statement  that  requires  that  It  be  placed  out-of-line. 
Similarly,  the  simulated  CASE  figure  requires  that  the  pro¬ 
grammer  code  explicit  GO  TO  statements  to  the  end  of  the 
figure,  whereas  with  the  precompiler  syntax,  such  statements 
are  generated  automatically.  Thus,  the  precompiler  Is 
Intended  to  achieve  the  twin  objectives  of  first,  easing  the 
task  of  writing  structured  COBOL,  and  second,  improving  the 
readability  of  such  code  thorugh  the  use  of  precompiler 
syntax  rather  than  simulated  structured  COBOL. 

G. 2  Precompiler  Inputs 

The  ANS  COBOL  precompiler  accepts  as  Input  an  ANS  COBOL 
program  written  In  precompiler  syntax  as  defined  in  Section 
G.4.  The  structuring  verbs  described  In  that  section  are 
processed  by  algorithms  described  in  Volume  II  of  the 
Structured  Programming  Series  to  produce  the  output  indicated 
in  Section  G.5.  These  structuring  verbs  should  be  viewed  as 
complete  sets  which  are  designed  to  be  processed  as  a  unit. 
Three  such  sets  are  processed  with  this  precompiler.  They  are 

a.  the  IF  set 

IF 

ELSE  (optional) 

ENDIF 

b.  the  DO  set 

DO 

ENDDO 
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the  CASE  set 


c . 


CASENTRY 

CASE  (at  least  one  suit  be  present) 

ELSECASE  (optional) 

EHDCASE 

G • 3  Precompiler  Output 

The  primary  output  of  the  precompiler  le  an  AMS  COBOL  (X3.23- 
1968)  compatible  compiler  input.  This  data  set,  input  to  the 
ANS  COBOL  compiler,  is  different  from  the  compiler  source 
code  listing  because  of  the  Intermediate  translation.  Comments 
are  Inserted  to  show  the  project  and  library  where  each  unit  of 
original  source  code  was  found.  Original  unlt-llne-numbers  are 
placed  in  columns  1  through  6  of  the  precompiler  output  for 
programmer  reference  if  necessary. 

A  second  type  of  precompiler  output  consists  of  error  messages 
as  appropriate  for  the  situation.  Error  messages  are  contained 
in  Section  C. 7  . 

The  relationship  between  the  precompiler  and  its  inputs  and 
outputs  is  graphically  displayed  by  the  following: 


G  .  4  COBOL  Precompiler  Input 


G.4.1  General  Information 

Thie  section  describes  the  foraat  of  all  Inputs  accepted  by 
the  precompiler.  These  Inputs  are  In  tvo  separate  data  sets. 

One  contains  the  option  card  and  the  second  the  structured  ANS 
COBOL  precompiler  Input.  £n  the  descriptions  which  follow, 
the  word  "condition"  means  any  valid  COBOL  condition  and 
"statement"  means  any  valid  COBOL  statement.  The  basic  formats 
of  these  Input  verbs  are  described  In  a  meta-language  which 
obeys  the  following  notation: 

a.  In  all  formats,  words  In  capital  letters  represent 
an  actual  occurrence  of  those  words.  If  eny  such 
word  is  Incorrectly  spelled,  it  will  not  be  recognized 
as  a  valid  Input  and  may  cause  an  error  in  the  program. 

b.  All  underlined  words  are  required  unless  the  portion 
of  the  format  containing  them  is  itself  optional. 

These  are  keywords .  If  any  such  word  Is  missing  or 
Is  incorrectly  spelled,  it  is  considered  an  error  in 
the  program. 

c.  Words  that  are  printed  in  lower-case  letters  represent 
information  to  be  supplied  by  the  programmer.  All 
such  words  are  defined  in  the  accompanying  text. 

d.  Square  brackets  ([]}  are  used  to  indicate  that  the 
enclosed  item  may  be  used  or  omitted,  depending  on 
the  requirements  of  the  particular  program. 

e.  The  ellipsis  (...)  indicates  that  the  immediately 
preceding  lower-case  word  may  occur  once,  or  any 
number  of  times  in  succession. 

f.  Comments,  restrictions,  and  clarifications  on  the  use 
and  meaning  of  every  format  are  contained  in  the 
appropriate  portions  of  the  text. 

In  all  the  examples  which  follow,  the  code  blocks  are  represented 
by  the  word  "statement"  in  order  to  be  conaistent  with  the  ANS 
COBOL  standards  manual.  However,  with  the  precompiler  it  is 
possible  to  place  multiple  sentences  and  even  paragraphs  between 
the  structuring  verbs  if  desired. 


G.4.2  Precompiler  Input  Formats 

Inputs  discussed  below  ere  the  control  structure  figures  CASE, 
D0WH1LE/D0UNTIL,  IFTHENELSE ,  INCLUDE,  end  the  unstructured  code 
.ON/. OFF  Indlcetors. 

G.4.2.1  CASE  Figure 

The  CASE  structure  figure  Is  used  to  pese  control  to  one  of  a 
set  of  statements  (or  series  of  statements)  depending  on  the 
value  of  an  Identifier. 

The  flowchart  for  the  CASE  control  structure  figure  Is: 


CASE 


and  It  is  coded  as: 
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Forma  t 


CAS ENTRY  identifier 


CASE  1  [ , numer ic-literal-1 ] 


statement-1 


CASE  2  [ , numer ic-literal-2 ] 


statement-2 


CASE  n  [ ,numeric-literal-n] . . 


statement-n 


ELSECASE 


statement 


ENDCASE [ . ] 


Control  1 8  transferred  to  one  of  a  series  of  statements, 
depending  on  the  value  of  identifier .  tfhen  ldentif ler  has  a 
value  of  1  (or  numer lc-llteral-1) ,  control  is  passed  to 
statement-1;  a  value  of  (or  numer ic-llteral-2)  causes  control 
to  be  passed  to  statement-2 ;  a  value  of  n  (or  numer ic -lit era 1-n) 
causes  control  to  be  passed  to  statement-n ■  The  identifier  must 
represent  an  unsigned  integer  (i.e.,  l,2,...,n).  If  the  value 
of  the  identifier  is  within  the  range  1_  through  n  but  not  equal 
to  one  of  the  CASE  numbers,  control  is  passed  implicitly  to  the 
sentence  following  the  ENDCASE.  If  the  value  of  the  identifier 
is  outside  of  the  range  .1  through  n,  the  ELSECASE  statement.  If 
one  is  present,  is  executed.  Control  is  then  passed  implicitly 
to  the  sentence  following  the  ENDCASE.  CASE  numbers  need  not 
be  in  numerical  sequence.  More  than  one  CASE  number  may  be 
associated  with  any  CASE  verb. 


Sta tement/ statement -n  may  consist  of  one  or  more  statements 
and/or  structured  figures. 

Identlf ler  Is  the  name  of  a  numeric  elementary  Item  described 
as  an  Integer.  Its  PICTURE  must  be  of  four  digits  or  less. 

Its  usage  must  be  DISPLAY  or  COMPUTATIONAL. 

G.4.2.2  DOWHILE/DOUNT IL  Figures 

The  DO  figures  are  used  to  depart  from  the  normal  sequence  of 
procedures  in  order  to  execute  a  statement,  or  a  series  of 
statements,  WHILE/UNTIL  a  predetermined  condition  Is  satisfied. 

The  flowchart  for  the  D0WH1LE  control  structure  figure  is: 


DOWKILE 


which  is  coded  as: 


_ Format 

DO  WHILE  condition 
statement 
ENDDOf . ] 


When  a  DOWEILE  is  executed,  the  following  action  is  taken: 

a.  Aa  long  aa  condition  us  tryem  tge  statement 
immediately  following  the  condition  (statement) 
is  executed. 

b.  If  condition  is  false,  the  next  sentence  which 
follows  the  ENDDO  is  sxecuted. 


« 

I 

■i 

1 


i 
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The  flowchart  for  the  DOUNTIL  control  structure  figure  is  • 


DOUNTIL 


and  It  Is  coded  as: 


When  a  DOUNTIL  is  executed,  the  following  action  Is  taken 
after  the  statement  Immediately  following  the  condition 
(statement)  Is  executed. 


a.  If  condition  is  true,  the  next  sentence  which 
follows  the  ENDDO  is  executed. 

b.  As  long  as  condition  remains  false,  the  statement 
immediately  following  the  condition  (statement) 
is  executed. 


S ta tement  in  both  DOWHILE  and  DOUNTIL  control  structure 
figures  may  consist  of  one  or  more  statements  and/or 
structure  figures. 


C.4.2.3  IFTHENE1 SE  Figure 

A  conditional  statement  specifies  that  the  truth  value  of  a 
condition  is  to  be  determined  and  that  the  subsequent  action 
of  the  object  program  is  dependent  on  this  truth  value.  The 
IFTHENELSE  structure  figure  causes  a  condition  to  be  evaluated 
with  the  subsequent  action  of  the  object  program  dependent 
upon  whether  the  condition  is  true  or  false. 
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The  flowchart  for  the  LFTHENELSE  control  structure  figure  Is: 


and  the  code  structure  to  be  used  to  represent  the  IFTHENELSE 
Is : 


_ Format 

IF  condition 
statement-1 
ELSE 

8  ta  tement -2 

ENDIF [ . ] 


If  an  IFTHENELSE  Is  executed,  the  following  action  Is  taken: 

a.  If  condition  is  true,  the  statement  immediately 
following  the  condition  (statement-1)  is  executed. 
Control  Is  then  passed  implicitly  to  the  next 
sentence  which  follows  the  ENDIF. 

b.  If  condition  is  false,  either  the  statement  following 
ELSE  (statement -2)  Is  executed,  or,  If  the  ELSE 
option  Is  omitted,  the  next  sentence  which  follows 
the  ENDIF  is  executed. 
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Statement-1  and  stateaent-2  in  the  IFTHENELSE  control  structure 
figure  map  consist  of  one  or  more  statements  and/or  structured 
figures.  If  a  structured  figure  appears  as  atatement-1  or 
statement-2 ,  it  is  said  to  be  nested.  Nesting  statements  is 
much  like  specifying  subordinate  arithmetic  expressions 
enclosed  in  parentheses  for  combination  into  larger  arithmetic 
expressions.  Indentation  by  PSL  unit  maintenance  programs 
highlights  both  the  structured  figure  and  any  nesting. 

G.4.2.4  INCLUDE  Figure 


An  INCLUDE  statement  is  used  to  refer  to  a  unit  which  will  be 
retrieved  and  substituted  in-line  for  the  INCLUDE  statement. 


The  flowchart  for  the  INCLUDE  figure  is: 


and  the  code  structure  to  be  used  to  represent  the  INCLUDE  is: 


In  Section  3.2.8. 

G  .4.2.5  Unstructured  Code  .ON/. OFF  Indicators 

It  should  be  noted  that  none  of  the  structuring  verbs,  except 
IF  and  ELSE,  are  contained  as  syntactical  elements  of  ANS  COBOL. 
Thus,  there  is  no  confusion  when  the  precompiler  processes  these 
verbs  for  translation.  However,  this  is  not  the  case  for  the  IF 
verb  set.  The  precompiler  IF  requires  a  matching  ENDIF  whereas 
the  COBOL  IF  does  not.  Thus,  any  IF  statement  which  is  processed 
by  the  precompiler  is  presumed  to  be  a  structuring  verb  and,  if 
a  corresponding  ENDIF  is  not  present,  erroneous  code  may  be 
generated.  However,  it  is  possible  to  pass  unstructured  code 
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(particularly  IF  statements)  through  the  precompiler  by 
Indicating  the  point  at  which  structured  processing  is  to  be 
suspended  and  the  point  at  which  it  is  to  be  resumed.  This 
is  done  by  using  the  character  strings  .ON  and  .OFF  as 
indicators  to  delimit  the  blocks  which  are  not  using  the 
control  structure  figures. 

The  format  of  the  precompiler  structured/unstructured  indi¬ 
cators  is  as  follows: 


and 


Format 


•  OFF 


The  .ON  keyword  indicates  that  all  code  which  follows  it,  up 
to  the  next  .OFF  indicator,  is  unstructured  and  is  not  to  be 
processed  by  the  precompiler.  The  .OFF  keyword  indicates 
that  the  end  of  the  unprocessed  code  has  been  reached  and 
structured  processing  is  to  be  reactivated.  These  keywords 
must  appear  on  a  single  card  (record)  and  must  start  in  area 
A  (columns  8  through  11) . 

G . 5  Precompiler  Output 

G.5.1  General  Information 


When  programming  in  a  top-down  manner  using  the  INCLUDE 
capability,  the  statements  in  a  small  segment  may  be  separated 
by  hundreds  of  lines  of  code  when  the  INCLUDES  are  resolved. 

In  order  to  facilitate  the  correspondence  between  the  pre¬ 
compiler  input  and  the  translation  to  ANS  COBOL  for  compiler 
input,  each  structured  figure  is  assigned  a  unique  number. 

This  number  is  used  in  the  generation  of  all  paragraph-names 
associated  with  the  complete  verb  set.  This  paragraph 
identification  scheme  is  in  addition  to  any  optional  mapping 
which  might  be  requested. 
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Precompiler  output  consists  of  messages  for  detected  errors 
and  a  translation  of  the  COBOL  input  Into  a  sequential  AMS 
COBOL  compiler  compatible  source  program.  This  section  is 
intended  to  describe  the  ANS  COBOL  generated  by  the  precompiler 
when  processing  the  COBOL  precompiler  Input. 

C.5.2  Precompiler  Code  Generation 

G.5.2.1  CASE  Figure 

The  CASE  structure  figure  is  used  to  pass  control  to  one  of  a 
set  of  statements  (or  a  series  of  statements)  depending  on  the 
range  of  the  identifier .  If  the  value  of  the  identifier  is 
within  the  range  1<  identifier  < n  (where  n  is  the  maximum  CASE 
number)  but  not  equal  to  one  of  the  CASE  numbers,  control  is 
passed  to  the  ENDCASE  collector.  If  the  value  of  identifier 
is  outside  the  range  1 _  identifier^  n.  the  ELSECASE  statement 
is  executed.  The  COBOL  precompiler  output  for  the  CASE  figure 
is  constructed  using  a  GO  TO ...  DEPENDING  ON  and  a  single 
collector  at  the  end  of  the  figure.  The  code  to  represent  the 
CASE  figure  is: 

CASENTRY  I 
CASE  4 

statement-1 
CASE  5,1 

statement-2 

ELSF.CASE 

statement 

ENDCASE. 

and  is  translated  as: 

1 - CSENTSY  . 

GO  TO  1 - CASETST. 

1 - CASE004 . 

statement-1 

GO  TO  1 - ENDCASE. 

1 - CASE005. 

1 - CASE001. 

statement-2 

GO  TO  1 - ENDCASE. 

1 - CASETST  . 

GO  TO  1 - CASE001  1 - ENDCASE 

1 - ENDCASE  1 - CASE004 

1 - CASE005 

DEPENDING  ON  I. 
statement 
1 - ENDCASE. 
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The  generated  paragraph-names  for  the  CASE  figure  start  in 
column  8  with  a  number  (each  use  of  any  figure  increments  the 
number,  which  is  limited  to  four  digits,  by  1)  followed  by 
dashes,  and  followed  by  the  word  CASENTRY,  CASEnnn,  CASETST, 
or  ENDCASE,  as  appropriate,  in  order  to  form  a  12-character 
paragraph-neme . 

G.5.2.2  DO WHILE/DO UNTIL  Figures 


The  COBOL  precompiler  output  for  the  DOWHILE  figure  is 
constructed  using  an  IF  statement  and  GO  TO  statements.  The 
condition  is  tested  prior  to  each  execution  of  statement 
including  the  first.  The  code  to  represent  the  DOWHILE 
figure  is: 


GO  TO  1 - DOTEST. 

1 - DOWHILE. 

statement 

1 - DOTEST . 

IF  (condition) 

GO  TO  1 - DOWHILE. 

1 - ENDDO. 


The  COBOL  precompiler  output  for  the  DOUNTIL  figure  is 
constructed  using  an  IF  statement  and  a  GO  TO  statement.  The 
condition  is  tested  after  each  execution  of  statement ,  so  that 
statement  is  always  executed  at  least  once.  The  test  on  the 
looping  condition  is  negated  by  applying  a  NOT  to  the  input 


condition .  The  code  to  represent  the  DOUNTIL  figure  is: 


1 - DOUNTIL. 

statement 

IF  NOT  (condition) 

GO  TO  1 - DOUNTIL. 

1 - ENDDO. 


The  generated  paragraph-names  for  both  the  DOWHILE  and  DOUNTIL 
figures  start  in  column  8  with  a  number  (each  use  of  any  figure 
increments  the  number,  which  is  limited  to  four  digits,  by  1), 
followed  by  dashes,  and  followed  by  the  word  DOUNTIL,  DOWHILE, 
DOTEST,  or  ENDDO,  as  appropriate,  in  order  to  form  a  12- 
character  paragraph-name. 
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G.5.2.3  IFTEENELSE  Figure 

The  COBOL  precompiler  output  for  the  IFTEENELSE  figure  Is  so 
constructed  that  the  "true"  conditional  code,  statement-1 . 
immediately  follows  the  IF  sentence.  In  order  to  Implement 
this  in  COBOL,  it  is  necessary  to  test  for  the  negative  of 
the  condition  by  using  a  MOT  (a  positive  test  would  necessi¬ 
tate  the  use  of  an  additional  GO  TO) .  The  code  to  represent 
the  IFTHENELSE  figure  is: 

1 - IF. 

IF  NOT  (condition) 

GO  TO  1 - ELSE. 

statement-1 
GO  TO  1 - ENDIF. 


1 - ELSE . 

statement-2 
1 - ENDIF. 


The  generated  paragraph-names  start  in  column  8  with  a  number 
(each  use  of  any  figure  Increments  the  number,  which  is  limited 
to  four  digits,  by  1),  followed  by  dashes,  and  followed  by  the 
word  ELSE  or  ENDIF,  as  appropriate,  in  order  to  form  a  12- 
character  paragraph-name. 

The  ELSE  la  the  IFTEENELSE  figure  is  optional  and  if  it  is  not 
used,  the  code  generated  is: 

1 - IF. 

IF  NOT  {condition) 

GO  TO  1 - ELSE. 

statement-1 

1 - ELSE. 

1 - ENDIF. 

The  GO  TO,  which  is  generated  when  the  IF  verb  is  detected,  is 
always  to  the  ELSE  paragraph-name  in  anticipation  of  the 
presence  of  one.  Therefore,  the  ELSE  paragraph-name  must  be 
generated  even  when  ELSE  code  is  not  present. 
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G . 6  COBOL  Compiler  Restriction! 

G.6.1  Reserved  Words 

The  following  additional  worda  are  added  to  the  ANS  COBOL 
reserved  word  list  when  using  the  precompiler: 

CASE 

CASENTRY 

DO 

ELSECASE 

END CASE 

ENDDO 

INCLUDE 

ENDIF 

WHILE 

UNTIL 

G.6.2  Paragraph-Names 

In  order  to  insure  uniqueness  of  paragraph-namea ,  the 
precompiler  user  may  not  code  any  such  names  in  the  format 
generated  by  the  precompiler.  A  description  of  the  format 
follows.  All  paragraph-names  are  12-character a  long.  They 
start  with  a  one  to  four  digit  number  and  terminate  with  one 
of  the  following  character  strings: 

CASEnnn  (nnn  is  a  number  padded  to  3  digits 
with  leading  zeroes  if  required) 

CASETST 

CSENTRY 

DOTEST 

DOUNTIL 

DOWHILE 

ELSE 

ENDCASE 

ENDDO 

ENDIF 

IF 

Separating  the  leading  digit  and  the  terminating  character 
string  are  as  many  dashes  as  requirsd  to  pad  the  paragraph- 
name  to  a  length  of  12  characters. 
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G.6.3  Structuring  Verb  Sets 

As  mentioned  in  Section  G.2,  the  precompiler  supports  three 
verb  sets,  namely,  IF,  DO,  and  CASE.  These  seta  have  starting 
verbs  (IF,  DO,  CASENTRY)  and  ending  verbs  (ENDIF,  ENDDO, 

ENDCASE)  and  are  designed  to  be  nested  ao  that  between  any  two 
members  of  a  set,  another  complete  set  may  be  Inserted,  thus 
Increasing  the  nesting  depth  by  one.  A  complete  set  is 
defined  as  one  having  both  a  starting  and  ending  verb. 

It  is  not  permissible  to  Intersperse  a  verb  from  one  set  in 
the  middle  of  another  set.  Thus,  the  sequence  of  verbs: 

IF 

DO 

ENDDO 

ELSE 

ENDIF 

is  a  valid  nesting,  but: 

IF 

DO 

ELSE 

ENDDO 

ENDIF 

la  not.  At  any  nest  level,  as  many  sets  as  required  may  be 
used,  provided  one  set  is  completed  before  the  next  one  Is 
started . 

G.6.4  Other  Restrictions 

The  following  additional  rules  must  be  followed  by  precompiler 
user 8 : 

a.  All  PERFORMS  must  be  written  as  PERFORM  paragraph- 
name-1  THRU  paragraph-name-2. 

b.  Every  COBOL  verb  (as  well  as  control  structure  verbs) 
must  appear  at  the  start  of  a  new  line. 

c.  All  control  structure  figures  and  the  INCLUDE  state¬ 
ment  as  defined  by  the  structure  verbs  are  to  be 
considered  conditional  statements.  They  may  not  be 
used  where  ANS  COBOL  syntax  calls  for  an  Imperative 
statement  such  as  in  an  arithmetic  statement  following 
ON  SIZE  ERROR,  in  READ/WRITE  statements  after  INVALID 
KEY,  following  the  AT  END  or  WHEN  in  a  SEARCH  state¬ 
ment,  and  other  such  occurrences. 
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Whenever  e  structuring  verb  Is  detected  by  the 
precompiler,  a  period  is  added  to  the  statement 
preceding  it  if  one  is  not  already  present.  Thus, 
if  the  previous  statement  was  a  COBOL  conditional 
statement,  the  presence  of  any  structuring  verb 
terminates  it. 

Any  code  inserted  in-line  by  a  COPY  statement  will 
not  be  scanned  by  the  precompiler. 


The  precompiler  error  messages  are  divided  Into  tvo  categories 
-—messages  which  result  from  an  error  condition  under  which 
the  precompiler  continues  processing,  and  messages  which 
result  from  conditions  under  which  processing  Is  terminated. 
The  two  categories  are  identified  by  separate  paragraphs. 


G.7.1  Errors  Which  Do  Not  Terminate  Processing 

When  errors  which  result  in  the  generation  of  any  messages  in 
this  subsection  are  detected,  the  precompiler  will  attempt  to 
take  corrective  action  where  possible.  However,  in  some  cases 
such  action  may  be  wrong  and  result  in  improper  execution. 
Therefore,  the  programmer  should  always  correct  his  code  to 
eliminate  these  messages. 


MSG  111  UNIT  unit-name  LINE  line-nbr 

CASE  ENTRY  STATEMENT  MISSING  NUMBER  IDENTIFIER. 
ERRONEOUS  CODE  MAY  RESULT. 

The  identifier  on  the  CASENTRY  verb  could  not 
be  found.  It  will  therefore  be  missing  when 
the  GO  TO ...  DEPENDING  ON  is  generated. 

MSG  112  UNIT  unit-name  LINE  line-nbr 

DO  STATEMENT  MISSING  WHILE  OR  UNTIL. 

WHILE  ASSUMED. 

A  WHILE  or  UNTIL  was  not  detected  after  a  DO. 

MSG  113  UNIT  unit-name  LINE  line-nbr 
CASE  FIGURE  HAS  NO  CASE. 


The  precompiler  did  not  find  any  CASE  verbs. 

The  GO  TO. . .DEPENDING  ON  is  not  generated  in 
this  instance.  If  an  ELSECASE  is  present, 
control  falls  into  this  code. 

MSG  114  UNIT  unit-name  LINE  li.te-nbr 

EXTRA  ELSECASE  FOUND  FOR  CASE  FIGURE  DISCARDED. 


The  precompiler  detected  more  than  one  ELSECASE 
as  part  of  a  CASE  statement.  In  this  instance 
control  falls  into  the  extra  ELSECASE  code. 


MSG  115  UNIT  unit-name  LINE  llne-nbr 

CASE  STATEMENT  FOUND  AFTER  ELSECASE  VILL  NOT 
BE  EXECUTABLE. 

The  code  comprising  the  misplaced  CASE  is 
unreachable . 

MSG  116  UNIT  unit-name  LINE  llne-nbr 

EXTRA  ELSE  STATEMENT  FOR  IF  FIGURE  DISCARDED. 

The  precompiler  has  detected  more  than  one 
ELSE  for  the  same  IF.  Control  falls  into  the 
extra  ELSE  code. 

MSG  117  UNIT  unit-name  LINE  line-nbr 

new-f lgure  ENCOUNTERED  BEFORE  IF  FIGURE 
TERMINATED.  ENDIF  ASSUMED  PRECEDING  new-f igure. 

This  error  message  is  generated  whenever  an 
intermediate  or  terminating  structure  verb, 
which  is  not  part  of  the  lowest  level  verb  set 
that  is  currently  open,  has  been  detected. 

Before  the  message  is  selected  for  output,  it 
is  first  determined  that  a  starting  verb  does 
exist  at  some  higher  nesting  level.  An  end  of 
file  condition  (EOF)  causes  a  similar  action. 

The  lines  at  the  beginning  and  end  of  each 
message  will  contain  the  verb  or  (EOF)  that 
does  not  match  the  lowest  level  open  verb  set. 

The  precompiler  assumes  that  the  proper  terminator 
for  that  nesting  level  was  omitted.  It  therefore 
terminates  the  figure  at  that  nest  level  and 
then  examines  the  next  figure  within  which  the 
terminated  figure  was  nested.  This  termination 
procedure  continues  until  the  nesting  level  is 
reached  with  the  proper  starting  verb.  That 
figure  Is  then  closed  and  normal  processing  is 
resumed . 

MSG  118  UNIT  unit-name  LINE  line-nbr 

new-f lgure  ENCOUNTERED  BEFORE  DO  FIGURE 
TERMINATED.  ENDDO  ASSUMED  PRECEDING  new-f igure. 

This  error  message  is  generated  whenever  an 
intermediate  or  terminating  structure  verb,  which 
is  not  part  of  the  lovest  level  verb  set  that  is 
currently  open,  has  been  detected.  Before  the 
message  is  selected  for  output,  it  is  first 
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determined  that  a  starting  verb  does  exist  at 
some  higher  nesting  level.  An  end  of  file 
condition  (EOF)  causes  a  similar  action.  The 
lines  at  the  beginning  and  end  of  each  message 
vlll  contain  the  verb  or  (EOF)  that  does  not 
match  the  lowest  level  open  verb  set.  The 
precompiler  assumes  that  the  proper  terminator 
for  that  nesting  level  was  omitted.  It 
therefore  terminates  the  figure  at  that  nest 
level  and  then  examines  the  next  figure  within 
which  the  termiaated  figure  was  nested.  This 
termination  procedure  continues  until  the 
nesting  level  Is  reached  with  the  proper 
starting  verb.  That  figure  Is  then  closed  and 
normal  processing  Is  resumed. 

MSG  119  UNIT  unit-name  LINE  line-nbr 

new-figure  ENCOUNTERED  BEFORE  CASE  FIGURE 
TERMINATED.  ENDCASE  ASSUMED  PRECEDING  new-flgure. 

This  error  message  is  generated  whenever  an 
Intermediate  or  terminating  structure  verb, 
which  Is  not  part  of  the  lowest  level  verb  set 
that  is  currently  open,  has  been  detected. 

Before  the  message  is  selected  for  output,  it 
is  first  determined  that  a  starting  verb  does 
exist  at  some  higher  nesting  level.  An  end  of 
file  condition  (EOF)  causes  a  similar  action. 

The  lines  at  the  beginning  and  end  of  each 
message  will  contain  the  verb  or  (EOF)  that  does 
not  match  the  lowest  level  open  verb  set.  The 
precompiler  assumes  that  the  proper  terminator 
for  that  nesting  level  was  omitted.  It  therefore 
terminates  the  figure  at  that  nest  level  and 
then  examines  the  next  figure  within  which  the 
terminated  figure  was  nested.  This  termination 
procedure  continues  until  the  nesting  level  is 
reached  with  the  proper  starting  verb.  That 
figure  is  then  closed  and  normal  processing  is 
resumed . 

MSG  120  UNIT  unit-name  LINE  line-nbr 
UNMATCHED  new-figure  DELETED. 

An  intermediate  or  terminating  structuring  verb 
cannot  be  matched  with  its  starting  verb.  The 
intermediate  or  terminating  verb  is  ignored. 
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MSG  121  UNIT  unit-name  LINE  line-nbr 

EXPECTED  CASE  NUMBER.  FOUND  WORD  user-word. 
WORD  DISCARDED. 

A  non-numeric  value  for  a  CASE  verb  was 
detected.  The  word  that  was  found,  Inserted 
where  the  blank  line  is,  is  ignored  by  the 
program . 

MSG  122  UNIT  unit-name  LINE  line-nbr 

OPTION  CARD  input-card-image  IN  ERROR 
DEFAULT  OPTIONS  -  NOSOURCE, MAP  -  ASSUMED. 

The  entire  80  column  input  card  is  printed 
where  input-card-image  is  indicated. 

G.7.2  Errors  Which  Terminate  Processing 

The  error  messages  which  follow  are  ones  which  suspend  pre¬ 
compiler  processing.  Six  of  them  are  caused  by  exceeding  the 
size  of  the  various  push  down  stacks  used  by  the  precompiler 
to  store  information.  In  some  of  the  cases,  if  the  program 
cannot  be  decreased  in  size,  it  may  be  necessary  to  increase 
the  size  of  the  stack  which  overflowed  and  recompile  the 
precompiler . 

MSG  123  UNIT  unit-name  LINE  line-nbr 

NEST-STACK  OVERFLOWED.  MAXIMUM  NUMBER  OF 
NESTED  STRUCTURE  FIGURES  50  EXCEEDED.  FATAL 
ERROR.  EXECUTION  TERMINATED. 

This  stack  contains  the  starting  verb  of  each 
verb  set  at  each  nested  level.  At  any  one  time 
in  the  program,  the  maximum  depth  to  which 
figures  may  be  nested  is  currently  set  at  50. 

MSG  124  UNIT  unit-name  LINE  line-nbr 

CONDITION-STACK  OVERFLOWED.  NESTED  DO 
CONDITIONS  OCCUPY  MORE  THAN  MAXIMUM  50  LINES. 
FATAL  ERROR.  EXECUTION  TERMINATED. 

The  conditionals  on  DO  statements  are  saved  in 
a  stack  and  removed  when  the  corresponding 
ENDDO  is  detected.  The  stack  is  set  to  hold 
50  cards  maximum. 
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MSG  125  UNIT  unit-name  LINE  line-nbr 

CASE-STACK  OVERFLOWED.  MAXIMUM  NUMBER  OF 
NESTED  CASES  10  EXCEEDED.  FATAL  ERROR. 
EXECUTION  TERMINATED. 

This  stack  controls  the  depth  to  which  one 
CASE  figure  may  be  nested  within  other  CASE 
figures.  The  current  maximum  is  set  at  10. 

MSG  126  UNIT  unit-name  LINE  line-nbr 

CASE-LABEL-STACK  OVERFLOWED.  MAXIMUM  NUMBER 
OF  CASE  NUMBERS  200  EXCEEDED.  FATAL  ERROR. 
EXECUTION  TERMINATED. 

This  stack  is  currently  set  to  hold  a  maximum 
of  200  CASE  numbers.  This  is  not  meant  to 
imply  that  only  200  CASE  numbers  may  be  present 
in  a  given  program  since  once  a  CASE  statement 
is  terminated  with  an  ENDCASE,  the  CASE  numbers 
associated  with  it  are  removed  from  the  stack. 

MSG  127  UNIT  unit-name  LINE  line-nbr 

LABEL-STACK  OVERFLOWED.  MAXIMUM  LABELS  125 
EXCEEDED.  CAUSED  BY  TOO  MANY  NESTED  STRUCTURE 
PICTURES.  FATAL  ERROR.  EXECUTION  TERMINATED. 

The  LABEL-STACK  holds  the  paragraph-names 
which  are  generated  by  the  precompiler.  The 
number  of  such  names  in  the  stack  at  any  one 
time  is  a  function  of  the  depth  of  nesting  at 
that  point  in  the  program.  The  current 
maximum  is  set  to  125. 

MSG  128  UNIT  unit-name  LINE  line-nbr 

OUTPUT-STACK  OVERFLOWED.  PROBABLY  CAUSED  BY 
TOO  MANY  BLANK  OR  CONTINUATION  LINES  FOR  ONE 
STATEMENT.  FATAL  ERROR.  EXECUTION  TERMINATED. 

OUTPUT-STACK  is  the  area  within  which  all 
processing  is  carried  on.  Input  records  are 
saved  in  this  stack  while  they  are  analyzed. 
Generated  paragraph-names  and  COBOL  statements 
are  also  placed  in  this  stack  prior  to  being 
directed  t  the  output  data  set.  This  stack 
is  normally  unloaded  prior  to  the  analysis  of 
the  next  COBOL  input  record.  The  current 
maximum  is  set  to  50. 
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MSG  129  UNIT  unit-name  LINE  line-nbr 

PROCEDURE  DIVISION  NOT  FOUND.  FATAL  ERROR. 
EXECUTION  TERMINATED. 

The  precompiler  was  unable  to  locate  the 
PROCEDURE  DIVISION  in  order  to  start  its 
processing . 

MSG  130  UNIT  unit-name  LINE  line-nbr 

MAXIMUM  NUMBER  OF  STRUCTURE  FIGURES  9999 
EXCEEDED.  FATAL  ERROR.  EXECUTION  TERMINATED. 

The  digital  value  placed  at  the  front  of  all 
precompiler  generated  paragraph-names  has 
been  exceeded . 
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APPENDIX  H. 


USERS  MANUAL  FOR  PSL  STRUCTURED  JOVIAL 
PRECOMPILER 


The  following  pages  of  this  appendix  provide  the  relevent 
information  on  the  JOCIT/JOVIAL  Precompiler*  of  the  PSL. 

This  precompiler  was  designed  for  the  JOVIAL  language 
augmented  with  structured  figures.  The  JOVIAL  language  is 
J0VIAL-J-3  as  defined  in  the  Air  Force's  document  AFM  100-24 
with  modifications,  as  indicated  in  the  JOCIT  Compiler's 
User's  Manual.  The  JOCIT/JOVIAL  Precompiler  was  developed 
to  process  structured  programming  figures  in  accordance  with 
the  standards  in  Programming  Language  Standards,  Volume  I  of 
the  Structured  Programming  Series,  RADC-74-200. 

H . 1  Precompiler  Objectives 

The  objective  of  the  JOVIAL  precompiler  is  to  assist  the  user 
in  writing  this  language  in  a  structured  format.  This  is 
achieved  by  defining  a  precompiler  syntax  which  introduces 
into  the  JOVIAL  language  the  statements  for  writing  structured 
CASE,  DOWHILE/DOUNTIL  and  IFTHENELSE  figures.  The  precompiler 
translates  these  statements  into  equivalent  expressions  in 
standard  JOVIAL  for  compilation  by  a  JOCIT/JOVIAL  compiler. 

An  INCLUDE  statement  is  also  introduced  into  the  precompiler 
syntax,  which  is  used  to  refer  to  a  unit  which  will  be 
retrieved  and  substituted  in-line  for  the  INCLUDE  statement. 

H . 2  Precompiler  Inputs 

The  JOVIAL  precompiler  accepts  as  input  a  JOVIAL  program 
written  in  precompiler  syntax  as  defined  in  Section  H.4.  The 
structuring  verbs  described  in  that  section  are  processed  by 
algorithms  to  produce  the  output  indicated  in  Section  H.5. 
These  structured  figures  should  be  viewed  as  complete  sets 
which  are  designed  to  be  processed  as  units.  Four  such  sets 
are  processed  with  this  precompiler.  They  are: 

a.  The  IF  set 

IF 

ELSE  (optional) 

END  I F 


*For  additional  information  regarding  this  capability  as  it 
was  developed,  see  the  Structured  Programming  JOCIT/JOVIAL 
Precompiler  produced  under  RADC  contract  F30602-76-C-0166 
by  IBM. 
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b.  The  DO  sets 

DO  (WHILE  or  UNTIL) 

ENDDO 

c.  The  CASE  set 

CASENTRY 

CASE  (at  least  one  must  be  present) 

ELSECASE  (optional) 

ENDCASE 

H . 3  Precompiler  Output 

The  primary  output  of  the  precompiler  Is  JOCIT/JOVIAL  compatible 
compiler  Input.  This  data  set.  Input  to  the  JOCIT/JOVIAL 
compiler,  Is  different  from  the  compiler  source  code  listing 
because  of  the  intermediate  translation.  The  precompiler  can 
produce  as  an  optional  output,  a  listing  of  the  JOVIAL  Input 
with  assigned  sequence  numbers  associated  with  each  statement 
on  the  source  listing.  By  exercising  a  second  option,  the  user 
may  request  that  the  sequence  numbers  on  this  source  listing  be 
Inserted  in  columns  73  through  80  of  the  precompiler  output 
(compiler  input)  and  subsequently  the  compiler  output  listings. 
Thus,  the  programmer  can  relate  a  statement  on  the  compiler 
output  listing  to  the  corresponding  precompiler  input.  Finally, 
a  third  precompiler  output  may  consist  of  error  messages 
(Section  H. 7) ,  should  any  errors  be  detected. 

The  relationship  between  the  precompiler  and  Its  inputs  and 
outputs  is  graphically  displayed  by  the  following: 


‘Optional  source  input  listing  sequence  numbers  in  columns  73-80. 
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H. A  JOVIAL  Precompiler  Input 
H.4.1  General  Introduction 

This  section  defines  the  formats  for  all  the  precompiler 
Inputs.  These  Inputs  are  In  two  separate  data  sets.  One 
contains  the  OPTION  CARD  and  the  second,  the  structured 
JOVIAL  precompiler  Input.  The  basic  formats  of  the  Input 
verbs  for  the  JOCIT/JOVIAL  precompiler  are  described  In  a 
meta-language  defined  In  the  JOVIAL  J3  program  language 
manual.  The  applicable  subset  of  this  meta-language  which 
Is  used  In  this  JOVIAL  subsection  follows: 

a.  In  all  formats,  words  In  capital  letters  represent 
occurrence  of  those  words.  If  any  such  word  is 
incorrectly  spelled,  it  will  not  be  recognized  as  a 
valid  input  and  may  cause  an  error  in  the  program. 

b.  Words  that  are  printed  In  lower-case  letters  represent 
Information  to  be  supplied  by  the  programmer.  All 
such  words  are  JOVIAL  defined  words. 

c.  In  the  descriptive  meta-language  for  JOVIAL,  the  colon 
is  used  to  connect  several  names  Into  a  single  com¬ 
posite  name.  Such  names  —  simple  and  composite  —  are 
meta-lingulstic  elements.  "Boolean:f ormula"  is  an 
example  of  this  notation. 

d.  Brackets  ([  ])  are  used  to  Indicate  that  the  enclosed 
Item  may  be  used  or  omitted. 

e.  The  vertical  elipsls  ('.)  is  used  to  in  the  CASE 
structure  to  indicate  that  the  CASE  verb  and  associated 
statement  may  occur  once,  or  any  number  of  times  in 
succession . 

f.  The  special  symbol  0  is  used  to  Indicate  that  one  or 
more  spacea  are  permitted. 

g.  Comments,  restrictions,  and  clarifications  on  the  use 
and  meaning  of  every  format  are  contained  in  the 
appropriate  portions  of  the  text. 

H.4.2  Precompiler  Input  Formats 

Inputs  discussed  below  are  the  control  structure  figures  CASE, 
DOWHILE/DOUNTIL,  IFTHENELSE ,  INCLUDE,  and  the  OPTION-CARD. 

H.4.2.1  CASE  Figure 

The  CASE:figure  is  used  to  pass  control  to  one  of  a  set  of 
statements  depending  on  the  value  of  a  numeric : formula . 
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The  flowchart  for  the  CASE:figure  la 


CASE 


ind  It  Is  coded  as: 


CASENTRY  0  numeric : formula  0  $ 
CASE  0  numeric : constant : list  $ 
Independent : statement 
“  CASE  0 
ind» 


i  numeric  :  constant :  list  $~| 
lependent : statement  J 


CASE  0  numeric 
independen 
ELSECASE 

Independent : statement 


c: constant. ’list  $~1 
t:statement  J 

] 


ENDCASE 


The  numeric : constant : list  consists  of  one  or  more  numeric 
:constants  separated  by  commas. 


In  executing  the  CASE:f igure,  the  numeric : formula  following 
the  CASENTRY  ia  evaluated  as  an  integer.  The  independent 
:statement  associated  with  the  CASE  number  corresponding  to 
the  value  of  the  numeric : formula  is  executed,  and  control  is 
then  passed  to  the  statement  following  the  ENDCASE.  If  the 
numeric : formula  yields  a  positive  value  that  does  not 
correspond  to  a  CASE  numeric : cons tant  in  the  list  but  with  a 
value  less  than  the  maximum  numeric : constant ,  the  execution 
sequence  continues  with  the  next  statement  following  the 
ENDCASE.  If  the  numer ic : f ormula  yields  a  negative  value  or 
zero,  or  a  positive  value  greater  than  the  maximum  numeric 
:constant  in  the  CASE:figure,  the  independent : statement 
associated  with  the  ELSECASE  is  executed. 

After  execution  of  any  statement  in  list,  the  execution 
sequence  continues  with  the  next  statement  following  the 
ENDCASE. 

BEGIN  and  END  brackets  within  a  CASE  are  not  required  when 
its  Independent : statement  is  a  compound : statement . 

H.4.2.2  DOWHILE/DOUNTIL  Figures 

The  DO  figures  allow  iterative  execution  of  an  independent 
:statement  based  on  the  value  of  a  Boolean : formula .  The 
value  of  the  Boolean : f ormula  is  tested  prior  to  the  execution 
of  the  independent : statement  In  a  DOWHILE : figure  and  after 
the  execution  of  the  independent : statement  in  a  DOUNTIL :f igure . 
The  flowchart  for  the  DOWHILE : f igure  Is: 


DOWHILE 


which  is  coded  is 


i  1 


DO  WHILE  9  Boolean : formula  9  $ 
Independent : statement 
EN  DDO 


'  The  DOWHILE : f igur e  executes  the  independent : s tatement  that 

physically  follows  the  DOWHILE : statement  as  long  as  the  value 
|  of  the  Boolean : formula  is  true.  The  Boolean : formula  is 

(  tested  prior  to  the  execution  of  any  statements  within  the 

range  of  the  DOWHILE : f igure  (i.e.,  the  statements  that 
physically  follow  the  DOWHILE,  up  to  and  Including  the  state- 
j  ment  preceding  the  ENDDO) .  BEGIN  and  END  brackets  are  not 

required  when  the  independen  t :  statement  is  a  compound  .'statement . 

\  The  flowchart  for  the  DOUNT TL : f igur e  is: 


DOUNT1L 


and  it  is  coded  a a: 


DO  UNTIL  9  Boolean : formula  9  $ 
independent: statement 
ENDDO 


The  DOUNTIL : f igur e  executes  the  independent : statement  that 
physically  follows  the  DOUNTIL :& tar ement  as  long  as  the  value 
of  the  Boolean : formula  is  false.  The  Boolean : formula  is 
tested  after  the  execution  of  any  statements  within  the  range 
of  the  DOUNTIL : f igur e  (i.e.,  the  statements  that  physically 
follow  the  DOUNTIL,  up  to  and  Including  the  statement  preceding 
the  ENDDO).  BEGIN  and  END  brackets  are  not  required  when  the 
independent : statement  is  a  compound : statement . 
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H.4.2.3  IFTHENELSE  Figure 


The  IFTHENELSE s figure  is  a  structured  conditional  statement 
providing  for  the  conditional  execution  of  one  of  two 
independent : statements  based  upon  the  value  of  a  Boolean : formula 

The  flowchart  for  the  IFTHENELSE : f igure  is: 


IFTHENELSE 

and  the  code  structure  to  be  used  to  represent  the  IFTHENELSE 
.‘figure  is: 


IF  8  Boolean : formula  8  $ 
Independent : statement-1 
"ELSE 

independent : statement-2_ 
ENDIF 


In  either  position  in  the  definition  of  the  IFTHENELSE : f igure , 
Independent : statement  is  a  simple : statement ,  a  compound 
:statement,  or  a  structured : f Igure  .  A  s true tured : f igure  is  an 
IFTHENELSE  .‘figure,  a  DOWHILE  :  f  igure  ,  a  DOUNTIL:  figure  ,  or  a 
CASE : f igure . 

The  effect  of  an  IFTHENELSE : f igure  is  that  if  the  value  of  the 
Boolean : formula  is  true,  independent : statement-1  which  follows 
it  is  executed;  otherwise,  independent : statement-2  following 
the  ELSE  is  executed.  BEGIN  and  END  brackets  are  not  required 
when  the  independent : s ta tement  is  a  compound : statement . 
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H.4.2.4  INCLUDE  Figure 


An  INCLUDE  statement  is  used  to  refer  to  s  unit  which  will  be 
retrieved  end  substituted  in-line  for  the  INCLUDE  ststement. 

The  flowchart  for  the  INCLUDE  figure  is: 


and  the  code  structure  to  be  used  to  represent  the  INCLUDE  is: 


1  FORMAT 

ststement 

INCLUDE 

unit-name 

i  statement 

A  more  detailed  description  of  INCLUDE  statements  is  contained 
in  Section  3.2.8. 

H.4.2.5  Option  Card 

The  option  card  Is  a  single  80-character  input  record  which 
contains  keywords  to  indicate  whether  a  listing  of  the  precompiler 
JOVIAL  input  is  to  be  generated.  This  listing  is  Intended  to 
assist  the  programmer  in  making  a  correlation  between  the  compiler 
source  code  listing  and  the  precompiler  JOVIAL  input.  The 
selection  of  options  is  contingent  upon  the  environment  in  which 
the  program  is  being  developed. 

The  card  is  optional.  Its  format  is: 


Forma  t 

"OPTION 

Uj 

T  SOURCE 

[[.]  1  ["AP  1 

_ 

L 

L  NOSOURCE 

L  L  J  J  L  nomapj 

While  Che  format  description  Indicates  SOURCE/NOSOURCE  keywords 
precede  MAP/NOMAP  keywords,  the  mutually  exclusive  keywords 
SOURCE/NOSOURCE  and  MAP/NOMAP  may  precede  or  follow  each  other. 
Their  appearance  is  restricted  to  columns  1  through  72  of  the 
option  card  and  they  may  be  separated  from  each  other  by  a  comma 
or  blank.  The  SOURCE  keyword  controls  the  option  as  to  whether 
a  sequenced  source  listing  of  the  precompiler  input  is  to  be 
produced.  The  MAP  keyword  indicates  that  the  sequence  numbers 
on  the  optional  precompiler  source  listing  are  to  be  placed  in 
columns  73  through  80  of  the  precompiler  output.  Default 
options  will  cause  a  precompiler  source  listing  and  will 
sequence  the  precompiler  output  data  set. 

H • 5  Precompiler  Output 

H.5.1  General  Information 


When  programming  in  a  top  down  manner  using  the  INCLUDE  capability, 
the  statements  in  a  small  segment  may  be  separated  by  hundreds  of 
lines  of  code  when  the  INCLUDES  are  resolved.  In  order  to 
facilitate  the  correspondence  between  the  precompiler  input  and  the 
translation  to  standard  JOVIAL  for  compiler  input,  each  structured 
figure  is  assigned  a  unique  number.  This  Identification  scheme 
is  in  addition  to  any  optional  mapping  which  might  be  requested. 

In  general,  precompiler  output  consists  of  messages  for  detected 
errors,  a  translation  of  the  source  input  into  a  compiler 
compatible  source  program,  and  an  optional  sequenced  listing  of 
the  precompiler  input. 

H.5.2  Precompiler  Code  Generation 

H.5.2.1  CASE  Figure 

The  CASE:flgure  is  used  to  pass  control  to  one  of  a  set  of  state¬ 
ments  depending  on  the  value  of  a  numeric : formula .  If  the  value 
of  the  numeric : formula  is  within  the  range  1  numeric : formula , 
n  (where  n  is  the  maximum  CASE  number)  but  not  equal  to  one  of  the 
CASE  number,  control  is  passed  to  the  ENDCASE  collector.  If  the 
value  of  numeric : formula  is  outside  the  range  1  numeric : formula 
n,  the  ELSECASE  independent : s tatement ,  is  executed;  otherwise, 
control  is  passed  to  the  ENDCASE  collector.  The  JOCIT/JOVIAL 
precompiler  output  for  the  CASE:figure  should  be  constructed 
around  a  awitch:declaration .  The  code  generated  by  the  JOVIAL 
precompiler  to  represent  this  CASE:flgure: 
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CASENTRY  NUMB  $ 

CASE  5,1  $ 

ALPHA  -  0.5  $ 

BETA  -  ALPHA**2  $ 
CASE  4  $ 

ALPHA  -  0.0  $ 
ELSECASE 

ALPHA  -  1.0  $ 

BETA  -  1.0  $ 
ENDCASE 


should  be: 


CASENTRY' 1  -  NUMB  $ 

GOTO  SWITCH' 1  $ 

CASE' 1' 5. 

CASE ' 1 ' 1 . 

ALPHA  -  0.5  $ 

BETA  -  ALPHA**2  $ 

GOTO  ENDCASE '1  $ 

CASE ' 1 ' 4 . 

ALPHA  -  0.0  $ 

GOTO  ENDCASE* 1  $ 

ELSECASE  *  1 . 

ALPHA  -  1.0  $ 

BETA  -  1.0  $ 

GOTO  ENDCASE' 1  $ 

SWITCH* 1. 

IF  CASENTRY *1  LS  1  OR 
CASENTRY '1  GR  5  $ 

GOTO  ELSECASE* 1  $ 

GOTO  SW'l  $  SW'l. 

SWITCH  CASENTRY ' 1  -  ( , CASE  '  1 ' 1 ,  ,  , 
CASE'1'4,CASE'1'5)  $ 

ENDCASE* 1. 

In  che  example  above,  a  value  of  1  or  5  for  NUMB  causes  the 
code  with  the  s tatement : names  CASE'1'5  and  CASE'1'1  to  be 
executed  with  ALPHA  set  equal  to  0.5  and  BETA  set  equal  to 
the  square  of  ALPHA.  A  value  of  4  for  NUMB  causes  CASE'1'4 
to  be  executed  with  ALPHA  set  equal  to  zero.  A  value  of  2 
or  3  for  NUMB  causes  control  to  be  passed  directly  to  che 
statement  following  the  ENDCASE'l  s tatement : name .  If  NUMB 
is  outside  the  range  1<  NUMB  <5,  the  ELSECASE'l  code  is 
executed  with  both  ALPHA  and  BETA  set  equal  to  1.0. 
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If  the  EL,.  ASE  had  been  omitted  on  input,  the  generated  code 
would  be: 

CASENTRY ' 1  -  NUMB  $ 

GOTO  SWITCH 1 1  $ 

CASE ' 1 ' 5 . 

CASE' 1 ' 1 . 

ALPHA  -  0.5  $ 

BETA  -  ALPHA**  2  $ 

GOTO  ENDCASE'l  $ 

CASE' 1 ' 4 . 

ALPHA  -  0.0  $ 

GOTO  ENDCASE'l  $ 

SWITCH' 1 . 

SWITCH  CASENTRY ' 1  -  (  , CASE ’ 1 ' 1  ,  ,  , 
CASE'1'4,CASE'1'5)  $ 

ENDCASE’l . 

The  generated  statement :namea  SWITCH'n,  SW'n,  and  ENDCASE'n, 
should  start  with  SWITCH,  SW,  and  ENDCASE,  respectively,  be 
followed  by  a  prime  ('),  and  an  unsigned  integer : constant 
without  a  scale.  The  integer : constant  should  begin  at  1  and 
be  incremented  by  1  for  each  occurrence  of  a  structured : f igure . 
The  switch:name  should  start  with  CASENTRY,  be  followed  by  a 
prime  ('),  and  also  be  followed  by  the  CASE :  f igure ' s  unique 
integer : constant .  The  CASE  statement :names  should  start  with 
CASE,  be  followed  by  a  prime  ('),  the  CASE : f igure '  s  unique 
integer : constant ,  another  prime  ('),  and  finally,  by  the 
appropriate  integer : constant  CASE  number  (unique  within  a 
CASE : f igure) .  Indentation  of  generated  code  should  be  as 
shown . 

Since  the  index  value  of  the  index : switch :declaration  points 
out  the  required  sequence : des igna tor  according  to  its  position 
In  the  list,  starting  with  zero  and  not  one,  the  index : switch : 
list  will  always  begin  with  a  comma,  since  a  zero  CASE  is  not 
permitted.  Commas  without  corresponding  sequence  :  designators 
indicate  case  values  which  were  not  defined  in  the  input 
CASE : f igure . 

H.5.2.2  DOWHILE/DOUNTIL  Figure 

The  JOCIT/JOVIAL  precompiler  output  for  the  DOWHILE : f igure 
should  be  constructed  using  an  lf:clause  and  go : to : statements  . 
The  Boolean : formula  is  tested  prior  to  each  execution  of 
independent : statement  Including  the  first.  The  code  to 
represent  the  DOWHI LE : f igure  1b: 
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GOTO  ENDDO'l  $ 

DOWHILE ' 1 . 

Independent : statement 
ENDDO'l.  IF  Boolean : formula  $ 

GOTO  DOWHILE '1  $ 

The  JOCIT/JOVLAL  precompiler  output  for  the  DOUNTIL : f igure 
should  be  constructed  using  an  if:clause  and  a  go:to:state- 
ment.  The  Boo  lean : formula  is  tested  after  each  execution 
of  independent : statement ,  so  that  independent : a tatement  is 
always  executed  at  least  once.  The  test  on  the  looping 
Boo  lean : formula  should  be  negated  by  applying  a  NOT  to  the 
input  Boolean : formula .  The  code  generated  by  the  JOVIAL 
precompiler  to  represent  the  DOUNTIL : f igure  is: 

DOUNTIL' 1. 

independent : statement 
IF  NOT  (Boolean : formula)  $ 

GOTO  DOUNTIL' 1  $ 

ENDDO'l. 

The  generated  statement : names  for  both  the  DOWHILE : f igure 
and  DOUNTIL : f igure  should  start  with  DOWHILE,  DOUNTIL,  and 
ENDDO,  respectively,  be  followed  by  a  prime  (')  and  an 
unsigned  Integer : constant  without  a  scale.  The  Integer 
:constant  for  each  shoula  begin  at  1  and  be  incremented  by 
1  for  each  appearance  of  a  structured : figure  to  create 
unique  statement : names . 

The  DOWHILE  and  ENDO  statement : names  should  be  aligned  as 
well  as  the  DOUNTIL  and  ENDDO  statement : names .  Generated 
statements  within  the  figures  should  be  aligned  as  indicated 
in  the  above  examples. 

H.5.2.3  1FTHENELSE  Figure 

The  IFTHENELSE : f igure  provides  for  the  conditional  execution 
of  one  of  two  independent : statements  based  upon  the  value 
of  a  Boolean: formula .  In  order  to  avoid  the  necessity  of 
using  BEGIN  and  END  brackets  for  the  independent : statements 
and  to  avoid  the  use  of  a  null  ORIF  when  the  optional  ELSE 
clause  is  not  used,  the  code  generated  by  the  JOVIAL 
precompiler  to  represent  the  IFTHENELSE : f igure  is: 

IF  NOT  (Boolean : formula)  $ 

GOTO  ELSE ' 1  $ 

Independent : statement-1 
GOTO  END IF ' 1  $ 

ELSE ' 1 . 

independent: statement-2 
END IF ' 1 . 
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The  generated  IF,  ELSE'n,  and  ENDIF'a  ahould  be  aligned  as 
were  the  original  (input)  IF,  ELSE,  and  ENDIF. 

The  ELSE  in  the  IFTH.ENELSE :  f  igure  ia  optional  and  if  it  la 
not  used,  the  code  to  represent  this  is: 

IF  NOT  (Boo  lean : f ormula )  $ 

GOTO  ELSE ' 1  $ 
independent :statement-l 
ELSE ' 1 . 

ENDIF' 1. 

The  generated  statements  should  be  aligned  as  indicated  above. 

The  generated  statement : names  in  both  of  the  above  examples 
should  start  with  ELSE  and  ENDIF,  respectively,  be  followed  by 
a  prime  (')  and  an  unsigned  in teger : cons tant  without  a  scale. 
The  integer : constant  should  begin  at  1  and  be  incremented  by 
1  for  each  appearance  of  a  structured  programming  figure  to 
create  unique  statement : names . 

H . 6  JOVIAL  Precompiler  Restrictions 

H.6.1  Primitives 


The  following  additional  words  are  added  to  the  JOCIT/JOVIAL 
primitive  list  when  using  the  precompiler: 

CASE 

CASENTRY 

DO 

ELSE 

ELSECASE 

ENDCASE 

ENDDO 

ENDIF 

UNTIL 

WHILE . 

H.6.2  Statement  Names  and  Variable  Names 


In  order  to  insure  uniqueness  of  statement  names  and  variable 
names  the  precompiler  user  must  avoid  coding  names  in  the 
format  generated  by  the  precompiler.  A  list  of  the  f>-mats 
follows : 
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( 

i 

I 

i 


i 


i 


! 

I 

I 

I 

I 

I 

I 

I 


STATEMENT  NAMES 

CASE 1 NNN 1 MMMMMM  (NNN  and  MMMMMM  are  respectively, 

3  and  6  digit  numbers  with  loading 
zeroes  intact) 

DOUNTIL' MMMMMM 
DOWHILE'  MMMMMM 
ELSE' MMMMMM 
EL SEC A SE' MMMMMM 
ENDCASE ’MMMMMM 
ENDDO 'MMMMMM 
END  IF 'MMMMMM 
SW' MMMMMM 
SWITCH ' MMMMMM 

VARIABLE  NAMES 

CAS ENTRY' MMMMMM . 

H.6.3  Structured  Figures 

As  mentioned  in  Section  2,  the  precompiler  supports  four 
structured  figures,  namely,  IFTHENELSE,  DOUNTIL,  DOWHILE ,  and 
CASE.  These  figures  have  starting  names  (IF,  DO  UNTIL,  DO 
WHILE,  CASENTRY)  with  corresponding  ending  names  (ENDIF, 

ENDDO,  ENDDO,  ENDCASE).  These  figures  may  be  nested.  That  is, 
the  independent  statements  within  any  struc tured :  f igure  may 
also  contain  completed  structured  figures.  Any  complete 
structured  figure  contained  within  another  Is  said  to  be  at  a 
nesting  depth  which  is  1  greater  than  the  containing  figure. 

It  is  not  permissible  to  overlap  figures  --  they  must  be 
nested.  Thus,  the  sequence: 

IF 

DO 

ENDDO 

ELSE 

ENDIF 

is  a  valid  nesting,  but: 

IF 

DO 

ELSE 

ENDDO 

ENDIF 

is  not. 
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H . 6 . 4  Other  Restrictions 


-  t 

The  following  additional  rules  must  be  followed  by  precompiler  | 

users: 

a.  Every  structure : word  (IF,  ELSE,  ENDIF,  CASENTRY, 

CASE,  2LSECASE ,  DO,  ENDDO)  must  appear  as  the  first 
symbol  on  the  input  record. 

i 

b.  Symbols  INCLUDE,  DIRECT  and  JOVIAL,  when  used,  must 

also  appear  as  the  first  symbol  on  the  input  record.  I 

{ 

c.  The  IF  statement  as  defined  in  standard  JOVIAL  must 
not  be  used.  Instead,  use  the  structure ifigure  IF. 

d.  GOTO  statements  should  not  be  used  except  when  used 
as  GOTO  CLOSE:name. 

H. 7  Error  Messages 

H.7.1  General  Information 

The  precompiler  error  messages  are  divided  into  two  categories. 

Those  messages  whose  numbers  are  less  than  100  are  errors  which 
are  detected  but  for  which  the  precompiler  continued  processing. 

Those  with  numbers  in  the  one  hundred  range  are  errors  for 
which  the  precompiler  processing  is  terminated  at  the  point  the 
error  was  detected.  In  this  case  the  compilation  should  also 
be  suspended.  However,  the  method  for  suspending  compilations 
is  a  system  dependent  function  and  not  addressed  by  the 
precompiler . 

H.7.2  Messages 

H. 7.2.1  Errors  Which  Do  Not  Terminate  Processing 

When  errors  which  result  in  the  generation  of  any  messages  in 
this  subsection  are  detected,  the  precompiler  will  attempt  to 
take  corrective  action  where  possible.  However,  in  many  cases 
such  action  may  be  wrong  and  result  in  Improper  program 
execution.  Therefore,  the  programmer  should  always  correct  his 
code  to  eliminate  these  messages. 

MSG  002  DO  MISSING  WHILE  OR  UNTIL.  WHILE  ASSUMED. 

A  WHILE  or  UNTIL  was  not  detected  after  a  DO. 


H-15 


MSG  003  CASE  FIGURE  HAS  NO  CASE. 

The  precompiler  did  not  find  any  CASE  verbs. 

If  an  ELSECASE  is  present,  control  falls  into 
this  code. 

MSG  004  EXTRA  ELSECASE  FOUND  FOR  CASE  FIGURE  DISCARDED. 

The  precompiler  detected  more  than  one  ELSECASE 
as  part  of  a  case  statement.  In  this  Instance 
control  falls  into  the  extra  ELSECASE  code. 

MSG  005  CASE  STATEMENT  FOUND  AFTER  ELSECASE  DISCARDED. 

The  code  comprising  the  misplaced  CASE  is 
unreachable . 

MSG  006  EXTRA  ELSE  STATEMENT  FOR  IF  FIGURE  DISCARDED. 

The  precompiler  has  detected  more  than  one  ELSE 
for  the  same  IF.  Control  falls  into  the  extra 
ELSE  code  . 

MSG  007  _ ENCOUNTERED  BEFORE  IF  FIGURE 

TERMINATED.  ENDIF  ASSUMED  PRECEDING  _ . 

This  error  message  is  generated  whenever  an 
intermediate  or  terminating  structure  word  that 
is  not  part  of  the  lowest  level  structure  that 
is  currently  open  has  been  detected.  Before  the 
message  is  selected  for  output  it  is  first 
determined  that  a  starting  word  does  exist  at 
some  higher  nesting  level.  An  end  of  file 
condition  (EOF)  causes  a  similar  action.  The 
lines  at  the  beginning  and  end  of  each  message 
will  contain  the  word  or  (EOF)  that  does  not 
match  the  lowest  level  open  structure.  The 
precompiler  assumes  that  the  proper  terminator 
for  that  nesting  level  was  omitted.  It  therefore 
terminates  the  figure  at  that  nest  level  and 
then  examines  the  next  figure  within  which  the 
terminated  figure  was  nested.  This  termination 
procedure  continues  until  the  nesting  level  is 
reached  with  the  proper  starting  word.  That 
figure  is  then  closed  and  normal  processing  is 
resumed . 
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MSG  008  _ ENCOUNTERED  BEFORE  DO  FIGURE  TERMINATED. 

ENDDO  ASSUMED  PRECEDING  _ . 

This  error  message  Is  generated  whenever  an 
intermediate  or  terminating  structure  word  that  is 
not  part  of  the  lowest  level  structure  that  is 
currently  open  has  been  detected.  Before  the 
message  is  selected  for  output  it  is  first  deter¬ 
mined  that  a  starting  word  does  exist  at  some 
higher  nesting  level.  An  end  of  file  condition 
(EOF)  causes  a  similar  action.  The  lines  at  the 
beginning  and  end  of  each  message  will  contain  the 
word  or  (EOF)  that  does  not  match  the  lowest  level 
open  structure.  The  precompiler  assumes  that  the 
proper  terminator  for  that  nesting  level  was 
omitted.  It  therefore  terminates  the  figure  at 
that  nest  level  and  then  examines  the  next  figure 
within  which  the  terminated  figure  was  nested. 

This  termination  procedure  continues  until  the 
nesting  level  is  reached  with  the  proper  starting 
word.  That  figure  is  then  closed  and  normal 
processing  is  resumed. 

MSG  009  _ ENCOUNTERED  BEFORE  CASE  FIGURE 

TERMINATED.  ENDCASE  ASSUMED  PRECEDING  _ . 

This  error  message  is  generated  whenever  an 
intermediate  or  terminating  structure  word  that 
is  not  part  of  the  lowest  level  structure  that 
is  currently  open  has  been  detected.  Before  the 
message  is  selected  for  output  it  is  first 
determined  that  a  starting  word  does  exist  at 
some  higher  nesting  level.  An  end  of  file 
condition  (EOF)  causes  a  similar  action.  The 
lines  at  the  beginning  and  end  of  each  message 
will  contain  the  word  or  (EOF)  that  does  not 
match  the  lowest  level  open  structure.  The 
precompiler  assumes  that  the  proper  terminator 
for  that  nesting  level  was  omitted.  It  therefore 
terminates  the  figure  at  that  nest  level  and  then 
examines  the  next  figure  within  which  the  term¬ 
inated  figure  was  nested.  This  termination 
procedure  continues  until  the  nesting  level  is 
reached  with  the  proper  starting  word.  That 
figure  is  then  closed  and  normal  processing  is 
resumed . 
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MSG  010  UNMATCHED  _  DELI  TED . 

An  Intermediate  or  terminating  structuring  word 
for  which  no  starting  word  of  the  same  structure 
can  be  detected  at  any  nested  level  has  been 
Ignored . 

MSG  Oil  ERROR  IN  CASE  NUMBER  DETECTED. 

A  numeric  value  for  a  CASE  was  not  detected. 

The  word  that  was  found  is  ignored  by  the  program. 


MSG 

012 

OPTION  CARD  ERROR. 

The  entire 
blank  line 

80  column  card 
is  Indicated. 

is  printed  where  the 

MSG 

014 

END 

OF  PROGRAM 

REACHED  WITHIN 

DO  FIGURE. 

The  end  of 
to  piocess 

Input  file  was 
the  DO  figure. 

reached  while 

attempting 

MSG 

015 

END 

OF  PROGRAM 

REACHED  WITHIN 

IF  FIGURE. 

The  end  of 
to  process 

input  file  was 
the  IF  figure. 

reached  while 

attempting 

MSG 

016 

END 

OF  PROGRAM 

REACHED  WITHIN 

CASENTRY  FIGURE. 

The  end  of 
to  process 

input  file  was 
the  CASE  flgur 

reached  while 

e . 

attempting 

MSG 

019 

DUPLICATE  CASE 

NUMBER  FOUND. 

Duplicate 

case  numbers  in 

a  structured 

f igure 

were  detected.  Second  number  discarded.  Some 
following  code  may  be  unreachable. 

H.7.2.2  Errors  Which  Terminate  Processing 

The  error  messages  which  follow  are  ones  which  suspend  precompiler 
processing.  Some  of  them  are  caused  by  exceeding  the  size  of  the 
various  push  down  stacks  used  by  the  precompiler  to  store  infor¬ 
mation.  In  some  of  these  cases,  if  the  program  cannot  be 
decreased  in  size  it  may  be  necessary  to  Increase  the  size  of  the 
stack  which  overflowed  and  recompile  the  precompiler. 
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MSG  101  CASE  NUMBER  STACK  OVERFLOWED.  MAXIMUM  OF  200 
EXCEED*®.  ''FATAL  ERROR.  EXECUTION  TERMINATED. 

This  stack  is  currently  set  to  hold  a  maximum 
of  200  CASE  numbers.  This  is  not  meant  to  imply 
that  only  200  CASE  numbers  may  be  present  in  a 
given  program  since  once  a  CASE  statement  is 
terminated  with  an  ENDCASE,  the  CASE  numbers 
associated  with  it  are  removed  from  the  stack. 

MSG  102  NEST  STACK  OVERFLOWED.  MAXIMUM  OF  300  EXCEEDED. 

FATAL  ERROR.  EXECUTION  TERMINATED. 

This  stack  contains  the  starting  and  intermediate 
structure  words  of  each  structure  set  for  which 
no  terminating  word  has  yet  been  encountered. 

The  maximum  depth  to  which  figures  may  be  stacked 
is  set  at  300. 

MSC  103  NEST  NUMBER  STACK  OVERFLOWED.  MAXIMUM  OF  50  EXCEEDED. 
FATAL  ERROR.  EXECUTION  TERMINATED. 

This  stack  contains  the  nest  numbers  of  each 
structured  figure  which  at  any  time  1m  £he  program 
has  not  yet  been  terminated ^  The  maximum  depth 
to  jrhicb  figures  may  be  nested  Is  thua  set  at  50. 

MSG  104  CONDITION  STACK  OVERFLOWED.  MAXIMUM  of  50  EXCEEDED. 
FATAL  ERROR.  EXECUTION  TERMINATED. 

.  V  .  ...  A  '  ' 

4  a  T 

The  conditions  on  DO  statements  -  are  saved  In  a 
stack  and  removed  wham  the  corresponding  SNDDO  is 
detected.  The  sTack  is  set  to  hold  50  cards 
maximum. 

MSG  105  CONDITION  COUNT  STACK  OVERFLOWED.  MAXIMUM  OF  50 
EXCEEDED.  FATAL  ERROR.  EXECUTION  TERMINATED. 

This  stack  is  also  used  with  DO  statements  to  keep 
track  of  the  number  of  cards  in  each  of  the 
conditions  stacked  in  the  condition  stack. 

MSG  108  MAXIMUM  NUMBER  OF  STRUCTURE  FIGURES  999999  EXECUTED. 
FATAL  ERROR.  EXECUTION  TERMINATED. 

The  digital  value  appended  to  all  statement  names 
generated  by  the  precompiler  to  assure  uniqueness 
has  been  exceeded. 
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APPENDIX  I.  GENERAL  PREPROCESSOR 


The  General  Preprocessor  is  an  addition  to  the  PSL  system 
which  provides  the  user  an  alternative  method  for  processing 
unstructured  source  code.  The  General  Preprocessor  allows 
unstructured  code  two  features  that  were  previously  only 
available  to  structured  SCOBOL,  SJOVIAL  or  SPFORT  source  code. 
These  features  are  Data  Compression  and  INCLUDE  Processing. 

The  General  Preprocessor  obtains  data  compression  by  allowing 
unstructured  source  code  to  be  stored  in  the  SOURCE  Section 
File  in  random  blocks.  Formerly,  unstructured  code  was 
stored  in  independent  files  as  sequential  card  images.  The 
code  in  SOURCE  Section  Files  has  trailing  blanks  removed  and 
with  the  CREATE  function  option  COMPRESS-YES  (which  is  the 
default  for  SOURCE  sections),  may  have  leading  blanks  removed 
also . 

INCLUDE  processing  is  handled  upon  compilation.  When  initiated 
by  the  COMPILE  function,  the  General  Preprocessor  scans  the 
unstructured  source  code  for  INCLUDE  statements  and  inserts 
the  included  units.  The  format  of  the  INCLUDE  statement  Is 
described  in  section  3.2.8. 

At  present  the  General  Preprocessor  accommodates  four 
languages:  ASM,  COBOL,  FORTRAN  and  JOVIAL.  To  use  the 

General  Preprocessor  the  user  need  only  ADD  the  unstructured 
source  code  with  the  keyword  LANGUAGE  set  to  ASM G ,  COBOLG . 
FORTRANG  or  JOVIAL G .  The  unit  type  (keyword  UTYPE)  will 
default  to  main  for  these  LANGUAGE  keyword  values.  The 
General  Preprocessor  is  called  automatically  by  the  COMPILE 
Function  and  is  net  requested  by  the  user. 
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APPENDIX  J 


PSL  SYSTEM  MANAGEMENT  FORMATS 


The  Management  (MGMT)  Section  of  the  system  project  and  library 
contains  management  data  format  units  patterned  after  the 
management  data  collection  requirements  determined  in  Volume  IX 
of  the  Structured  Programming  Series.  An  Index  of  this  MGMT 
Section  or  source  listing  of  the  referenced  format  units  Is 
given  here  to  acquaint  the  PSL  user  with  their  contents.  The 
formats  may  be  moved  (all  or  in  part)  to  a  user-specified 
MGMT  Section  (refer  to  paragraph  3.4.15  for  specific  details) 
after  which  they  may  be  modified  and/or  directly  utilized  to 
facilitate  the  collection  of  management  data. 
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